0x74 


SrclkPre 


14 


0x0000 


Number of pclk cycles between 
phijsyncl falling edge and phi_srclk 
Dulse generation, or printhead data 
transfer 


0x78 


SrclkPost 


14 


0x0000 


Number of pclk cycles allowed margin 
from last srclk pulse in a line to before 
next line sync 


0x7C-0x80 


PrintHeadRate[ 
1:0] 


2x16 


OxFFFF 


Specifies the active to inactive ratio of 
phLsrc/k for the printhead ICs. A 1 
indicates Active. 
Bus 0 - Printhead IC channel A 
Bus 1 - Printhead IC channel B 


0x84 


DotOrderMode 


1 


0x0 


Specifies the dot transmit order to the 
printhead Channel A. Printhead 
Channel B is always the opposing 
order. 

0 - Even before Odd dots 

1 - Odd before Even dots 


Fire Control 


0x98 


FrclkPre 


14 


0x0000 


Number of pclk cycles after Isyncl 
transitions from 0 to 1 to phljrclk 
pulse generation 


0x9C 


FrclkLow 


14 


0x0000 


Number of pclk cycles phljrclk should 
remain low. 


OxAO 


FrclkHigh 


14 


0x0000 


Number of pclk cycles phljrclk should 
remain high. 


0xA4 


FrclkNum 


16 


0x0000 


Number of phljrclk pulses per line 
time. 


0xA8 


FireGenSoftTri 

gger 


1 


0x0 


Only active when 

PrintHeadCpuCtrlMode is set to 1 , 
PrintHeadCpuCtrl is 1 and pin is in 
output mode. 

Bit 0 controls frclk generator. 

A 0 to 1 transition on a bit triggers the 

corresponding generator to create the 

programmed pulse profile (configured 

by 

FrclkNum.FrclkHigh.FrclkLow.FrclkPre 
registers) when complete the bit gets 
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10 



15 



20 



25 



30 



35 











reset to 0. 


Working Registers 


OxAC-OxBO 


UneDotCnt 


2x16 


0x0000 


Indicates the number of dot processed 

in the current line 

Bus 0 - Printhead Channel A 

Bus 1 - Printhead Channel B 

(Read Only Registers) 



The configuration registers in the PHI block are clocked at pclk rates but some blocks in the PHI 
are clocked by different and asynchronous clocks. Configuration values are not re-synchronized, it 
is therefore important that the Go register be set to zero while updating configuration values. This 
prevents logic from entering unknown states due to metastable clock domain transfers. 
Some registers can be written to at any time such as the direct CPU control registers 
(PrintHeadCpuIn, PrintHeadCpuDir, PrintHeadCpuOut and PrintHeadCpuCtrl), the Go register 
and the PrintStart register. All registers can be read from at any time. 
32.9.4 Dot counter 

The dot counter keeps a running count of the number of dots fired for each color plane. The 
counters are 32 bits wide and will saturate. When the CPU wants to read the dot count for a 
particular color plane it must write to the DotCountSnap register. This causes all 6 running counter 
values to be transferred to the DotCount registers in the configuration registers block. The running 
counter values are reset. 

// reset if being snapped 
if < dot_cnt_snap == 1) then{ 

dot_count [5:0] = accum_dot_count [5:0] 

accum_dot_count [5:0] = 0 

} 

// update the counts 

for (color=0 ; color < 6;color++) { 

if (accum_dot__count [color] != 0xffff_ffff) { 
// data valid, first dot stream 

data_valid = ( (phi_llu_ready [0] == 1) AND 
(llu_phi_avail [0] == 1)) 

if ( (data_valid == 1) AND ( llu_phi_data [0] [color] = = 
1) ) then 

accum_dot_ count [color] ++ 

// data valid, second dot stream 

data_yalid = ( <phi_llu_ready [1] == 1) AND 
(llu_phi_avail [1] == 1)) 

if ((data_valid == 1) AND ( llu_phi_data [1] [color] == 
1 ) ) then 

accum dot count [color] ++ 



} 



} 



32.9.5 Sync generator 
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The sync generator logic has two modes of operation, master and slave mode. In master mode 
(configured by the PhiMode register) it generates the lsyncf_o output based on configured values 
and control triggers from the PHI controller. In slave mode it de-glitches the incoming IsynclJ 
signal, and filters the Isyncl signal with the minimum configured period. 
5 After reset or a pulse on phi_go _pulse the machine returns to the Reset state, regardless of what 
state it's currently in. 

The state machine waits until it's enabled (sync_en==1) by the PHI controller state machine. 
When enabled it can proceed to the SyncPre or SyncWait depending on whether the state 
machine is configured in master or slave mode. In master mode it generates the Isyncl pulses, in 
1 0 slave mode it receives and filters the Isyncl pulses from the master sync generator. 

On transition to the SyncPre state a counter is loaded with the LsyncPre value, and while in the 
SyncPre the counter is decremented. When the count is zero the machine proceeds to the 
SyncLow state loading the counter with LsyncLow value. 

The machine waits in the SyncLow state until the counter has decremented to zero. It proceeds to 
1 5 the SyncHigh state pulsing the line_st signal on transition and counts LsyncHIgh number of 

cycles. This indicates to the PHI controller the line start aligned to the Isyncl positive edge. While 

in LsyncLow state the IsyncLo output is set to 0 and in SyncHigh the lsyncl_o output is set to 1 . 

When the count is zero and the current line is not the last (lastjine == 0), the machine returns to 

the SyncLow state to begin generating a new line sync pulse. The transition pulses the linejin 
20 signal to the PHI controller. 

The loop is repeated until the current line is the last (lastjine ==1), and the machine returns to the 

Reset state to wait for the next page start. 

In slave mode the state machine proceeds to the SyncWait state when enabled. It waits in this 
state until a-lsync _pulse_rise is received from the input de-glitch circuit. When a pulse is detected 

25 the machine jumps to the SyncPeriod state and begins counting down the Lsynctiigh number of 
clock cycles before returning to the SyncWait state. Note in slave mode the Lsynctiigh specifies 
the minimum number of pclk cycles between Lsync pulses. On transition from the SyncWait to the 
SyncPeriod state the line_st signal to the PHI controller is pulsed to indicate the line start. While in 
the SyncPeriod state if a lsync_pulse_fall is detected the state machine will signal a sync error 

30 (via sync_err) to the PHI controller and cause a buffer underrun interrupt. 
32. 9. 5. 1 Lsyncl input de-glitch 

The IsyncJ input is considered an asynchronous input to the PHI, and is passed through a 
synchronizer to reduce the possibility of metastable states occurring before being passed to the 
de-glitch logic. 

35 The input de-glitch logic rejects input states of duration less than the configured number of clock 
cycles (Isync^deglitch^cnt), input states of greater duration are reflected on the output, and are 
negative and positive edge detected to produce the lsync_pulse_fall and lsync_pulse_rise signal 
to the main generator state machine. The counter logic is given by 

if ( lsync_i I = lsync_i_delay) then 
40 cnt = lsync_deglitch_cnt 
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output_en = 0 
elsif (cnt == 0 ) then 
cnt = cnt 

output_en = 1 
5 else 

cnt - - 

output_en = 0 
32. 9. 5. 2 Line Sync Interrupt logic 

The line sync interrupt logic counts the number of line syncs that occur (either internally or 
1 0 externally generated line syncs) and determines whether to generate an interrupt or not. The 
number of line syncs it counts before an interrupt is generated is configured by the 
LineSynclnterrupt register. The interrupt is disabled if LineSynclnterrupt is set to zero. 

// implement the interrupt counter 
if (phi_go_pulse ==1) then 
15 line_count = 0 

elsif (line_st == 1) AND (line_count == 0)) then 

line_count = linecount_int 
elsif ( (line_st == 1) AND (line_count i= 0)) then 

line_count 

20 // determine when to pulse the interrupt 

if (linesync_int 0 ) then // interrupt disabled 

phi_icu_linesync__int = 0 ; 
elsif ( (line_st == 1) AND (line_count == 1)) then 
phi_icu_linesync_int = 1 
25 32.9.6 Fire generator 

The fire generator block creates the signal profile for the phijrclk signal to the printhead. The 
frclk is based on configured values and is timed in relation to the fire_st pulse from the PHI 
controller block. Should the phijrclk state machine receive a fire_st pulse before it has completed 
the sequence the machine will restart regardless of its current state. 
30 Alternatively the frclk state machine can be triggered to generate their configured pulse profile by 
software. A low to high transition on the FireGenSoftTrigger register will cause a pulse on 
softJrclk_$t triggering the state machine to begin generating the pulse profile. When the state 
machine has completed its sequence it will clear the FireGenSoftTrigger register bit (via 
soft_fire_clr signal). The FireGenSoftTrigger register will only be active when the printhead 
35 interface is in CPU direct control mode (PrintHeadCpuCtrl = 1) , the fire generator is in software 
trigger mode (PrintHeadCpuCtrlMode[x] = 1) and the pin is configured to be output mode 
(PrintHeadCpuDir[x] = 1 ). 

The fire generator consists of a state machine for creating the phijrclk signal. The phijrclk signal 
is generated relative to the Isyncl signal. 
40 The machine is reset to the Reset state when phLgo _pulse ==1 or the reset is active, regardless 
of the current state. 

The machine waits in the reset state until it receives a fire_st pulse from the PHI controller (or an 
soft_fire_st from the configuration registers). The controller will generate a fire_st pulse at the 
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beginning of each dot line. On the state transition the cycle counter is loaded with the Frc/kPre 
value and the repeat counter is loaded with the FrclkNum value. 

The state machine waits in the FirePre state until the cycle counter is zero, after which it jumps to 
the FireHigh state and loads the cycle counter with FrclkHigh value. Again the state machine 
5 waits until the count is zero and then proceeds to the FireLow state. On transition the cycle 

counter is loaded with the FireLow value. The state machine waits in the FireLow state while the 
cycle counter is decremented. 

When the cycle counter reaches zero and the repeat_count is non-zero, the repeat_count is 
decremented, the cycle counter is loaded with the FrclkHigh value and the state machine jumps to 
1 0 the FireHigh state to repeat the phi_frclk generation cycle. The loop is repeated until the 
repeat_count is zero. In such cases the state machine goes to the reset state resetting 
FireGenSoftTrigger (via the soft_fire_clr signal) register on the transition and waits for the next 
fire_st pulse. 

When in the Reset state the fire_rdy signal is active to indicate to the controller that the fire 
1 5 generator is ready. 

32.9.7 PHI controller 

The PHI controller is responsible for controlling all functions of the PHI block on a line by line 
basis. It controls and synchronizes the sync generator, the fire generator, and datapath unit, as 
well as signalling back to the CPU the PHI status. It also contains a line counter to determine 

20 when a full page has completed printing. 

The PHI controller state machine is reset to Reset state by a reset or phi_go_pulse == 1 . 
It will remain in reset until the block is enabled by phLgo == 1 . Once enabled the state machine 
will jump to the FirstLine state, trigger the transfer of one line of data to the printhead (data_st == 
1) and the line counter will be initialized to the page length (PageLenLine). Once the line is 

25 transferred (datajin from the datapath unit) the machine will go to Printstart state and signal the 
CPU using an interrupt that the PHI is ready to begin printing (phi_icu_print_rdy). The line counter 
will also be decremented. It will then wait in the Printstart state until the CPU acknowledges the 
print ready signal and enables printing by writing to the Printstart register. 
The state machine proceeds to the SyncWait state and waits for a line start condition (line_$t 

30 ==1). The line start condition is different depending on whether the PHI is configured as being in a 
master or slave SoPEC (the PhiMode register). In either case the sync generator determines the 
correct line start source and signals the PHI controller via the line^st signal. Once received the 
machine proceeds to the LineTrans state, with the transition triggering the fire generator to start 
(fire_st), the datapath unit to start (data_st) and the sync generator to start (sync^st). 

35 While in the LineTrans state the fire, sync and datapath unit will be producing line data. When 

finished processing a line the datapath unit will assert the line finished (datajin) signal. If the line 
counter is not equal to 1 (i.e. not the last line) the state machine will jump back to the SyncWait 
state and wait for the start condition for the next line. The line counter will be decremented. If the 
line counter is one then the machine will proceed to the LastLine state. 
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The LastLine state generates one more line of fire pulses to print the last line held in the shift 
registers of the printhead. Once complete (fire Jin ==1) the state machine returns to the reset 
state and waits for the next page of data. On page completion the state machine generates a 
phijcu_pagejnish interrupt to signal to the CPU that the page has completed, the 
5 phijcu_page_finish will also cause the Go register to reset automatically. 

While the state machine is in the LineTrans state (or in FirstLine state and the PHI is in slave 
mode) and waiting for the datapath unit to complete line processing, it is possible (e.g. an 
excessive PEP stall) that a line finish condition occurs (line Jin == 1) but the datapath unit is not 
ready. In this case an underrun error is generated. The state machine goes to the Underrun state 
1 0 and generates a phijcu_underrun interrupt to the CPU. The PHI cannot recover from a buffer 
underrun error, the CPU must reset the PEP blocks and re-start printing. The phijcu_underrun 
will also cause the Go register to reset automatically. 
32.9.8 CPU IO control 

The CPU IO control block is responsible for providing direct CPU control of the IO pins via the 
1 5 configuration registers. It also accepts the input signals from the printhead and re-synchronizes 

them to the pcik domain, and debug signals from the RDU and muxes them to output pins. 

Table contains the direct mapping of configuration registers to printhead IO pins. Direct CPU 

control is enabled only when PrintHeadCpuCtrl is set to one. In normal operation (i.e. 

PrintHeadCpuCtrl == 0) the printhead frclk pin is always in output mode (p/?/_/rc//c_e=1), the 
20 phiJsynclW\\\ be in output if the SoPEC is the master, i.e. phijsyncl_e = phi_mode t and read/ will 

be set high. 

The PrintHeadCpuCtrlMode register determine whether the frclk pin should be driven by the fire 
generator logic or direct from the CPU PrintHeadCpuOut register. 
The pseudocode for the CPU IO control is: 

25 if (printhead_cpu_ctrl == 1) then // CPU access enabled 

// outputs 

if (PrintHeadCpuCtrlMode [0] == 1) then // fire 

generator controlled 

phi_frclk_o = frclk 

30 else // normal 

direct CPU control 

phi_f rclk_o = printhead_cpu_out [1] 

phi _ph_data_o [0] [1:0] = printhead_cpu_out [4 : 3] 
phi_ ph_data_o [1] [1:0] = print he ad_cpu_out [6 : 5] 
35 phi_srclk [1 : 0] = print he ad_cpu_out [8 : 7] 

phi_readl = printhead_cpu_out [9] 

// direction control 

phi_lsyncl_e = printhead_cpu_dir [0] 

phi_frclk_e = print head_cpu_dir [1] 

40 // input assignments 

printhead_cpu_in [0] = synchronize (phi_l sync l_i) 
printhead_cpu_in [1] = synchronize (phi_frclk_i) 
else // normal connections 
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// outputs 

phi_ph_data_o [0] [1:0] = ph_data[0] [1:0] 
phi_ph_data_o [1] [1:0] = ph_data[l] [1:0] 
phi_lsyncl_o = lsync_o 

5 phi_readl = 1 

phi_srclk[l:0] = srclk[l:0] 

phi_f rclk_o = f rclk 

// direction control 
phi_frclk_e = 1 

10 phi_lsyncl_e = phi_mode // depends on Master 

or Slave mode 
// inputs 

lsyncl_i = phi_lsync_i // connected 

regardless 

15 // debug overrides any other connections 

if (debug_cntrl [0] == 1) then 

phi_frclk_o = debug_data_valid 

phi_frclk_e = 1 

phi_readl = pclk 

20 The debug signalling is controlled by the RDU block (see Section 11.8 Realtime Debug Unit 
(RDU)), the IO control in the PHI muxes debug data onto the PHI pins based on the control 
signals from the RDU. 

32.9.9 Datapath Unit 

32.9. 1 0 Dot order controller 

25 The dot order controller is responsible for controlling the dot order blocks. It monitors the status of 
each block and determines the switch over point, at which the connections from odd and even dot 
streams to printhead channels are swapped. 

The machine is reset to the Reset state when phi_go_pulse == 1 or the reset is active. The 
machine will wait until it receives a data_st pulse from the PHI controller before proceeding to the 
30 LineStart state. On the transition to the LineStart state it will reset the dot counter in each dot 
order block via the dot_cnt_rst signal. 

While in the LineStart state both dot order blocks are enabled (gen_en==1). The dot order blocks 
process data until each of them reach their mid point. The mid point of a line is defined by the 
configured printhead size (i.e. print_head_size). When a dot order block reaches the mid point it 
35 immediately stops processing and waits for the remaining dot order block. When both dot order 
blocks are at the mid point (mid_pt == 1 1) the controller clocks through the LineMid state to allow 
the pipeline to empty and immediately goes to LineEnd state. 

In the LineEnd state the mode^sel is switched and the dot order blocks re-enabled, in this state 
the dot order blocks are reading data from the opposite LLU dot data stream as in LineStart state. 
40 The controller remains in the LineEnd state until both dot order blocks have processed a line i.e. 
line Jin ==11. 
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On completion of both blocks the controller returns to the Reset state and again awaits the next 
data_st pulse from the PHI controller. When in Reset state the machine signals the PHI controller 
that it's ready to begin processing dot data via the dot_order_rdy signal. 
The dot order controller selects which dot streams should feed which printhead channels. The 
5 order can be changed by configuring the DotOrderMode register. In all cases Channel A and 
Channel B must be in opposing dot order modes. Table 216 shows the possible modes of 
operation. 

Table 216. Mode selection in Dot order controller. 



Channel 


Mode_sel 


DotOrderMode 


Dot transmit order 


A 


0 


0 


Even before Odd (EBO mode), even dot 
stream Teeas onannei a pnntneaa, Tirst nan 
line. 




0 


1 


Odd before Even (OBE mode), odd dot 
stream Teeas ^nannei a pnntneaa, nrst nan 
line. 




1 


0 


Even before Odd (EBO mode), even dot 
stream Teeas ^nannei a pnntneaa, secona 
half line. 




1 


1 


Odd before Even (OBE mode), odd dot 

otroom fooHc r* honnol A nrinthooH corAnrl 
SirealTI IccUb ldliritJI r\ pi II UllcdU, bcUUilU 

half line. 


B 


0 


0 


Odd before Even (OBE mode), odd dot 
stream feeds Channel B printhead, second 
half line 




0 


1 


Even before Odd (EBO mode), even dot 
stream feeds Channel B printhead, second 
half line. 




1 


0 


Odd before Even (OBE mode), odd dot 
stream feeds Channel B printhead, first half 
line. 




1 


1 


Even before Odd (EBO mode), even dot 
stream feeds Channel B printhead, first half 
line. 



1 0 32. 9.10.1 Dot order unit ~ — 

The dot order control accepts dot data from either dot stream from the LLU and writes the dot 
data into the dot buffer. It has two modes of operation, odd before even (OBE) and even before 
odd (EBO). In the OBE mode data from the odd stream dot data is accepted first then even, in 
EBO mode it's vice versa. The mode is configurable by the DotOrderMode register. 
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The dot order unit maintains a dot count that is decremented each time a new dot is received from 
the LLU. The dot order controller resets the dot counter to the print_head_size[1 5:0] at the start of 
a new line via the dot_cnt_rst signal. The dot count is compared with the printhead size 
(print_head_size[15:0] divided by 2) to determine the mid point (mid_pt) and the line finish point 
5 (line_fin) when the dot counter is zero. 

The mid point is defined as the half the number of dots in a particular printhead, and is derived 
from the the print_head_size bus by dividing by 2 and rounding down. 
// define the mid point 

if (dot_cnt [15 : 0] == print_head_size [15 : 1] ) then 
10 mid_pt = 1 

else 

mid_pt = 0 

The dot order unit logic maintains the dot data write pointer. Each time a new dot is written to the 
dot buffer the write pointer is incremented. The fill level of the dot buffer is determined by 
1 5 comparing the read and write pointers. The fill level is used to determine when to backpressure 
the LLU (ready signal) due to the dot buffer filling. A suitable threshold value is determined to 
allow for the full LLU pipeline to empty into the dot buffer. 
The dot order stalling control is given by: 

// determine the ready/ avail signal to use, based on mode 
20 select 

if (mode_sel == 1) then 

dot_active = llu_phi_avail [0] AND ready 
wr_data = llu_j?hi_data [0] 
else 

25 dot_active = llu_phi_avail [1] AND ready 

wr_data = llu_phi_data [1] 
// update the counters 
if (dot_active == 1) then { 

wr_en = 1 

30 wr_adr ++ 

if (dot_cnt == 0) then 

dot_cnt = print_head_size 
else 

dot_cnt - - 

35 } 

The dot writer needs to determine when to stall the LLU dot data stream. A number of factors 
could stall the dot stream in the LLU such as buffer filling, waiting for the mid point, waiting for the 
line finish or the dot order controller is waiting for the line start condition from the PHI controller. 
The stall logic is given by: 

40 // determine when to stall the LLU generator 

filial evel = wr_adr - rd_adr 

if (fill_level > (32 - THRESHOLD ) ) then // THRESHOLD is 
open value 
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ready = 0 
to full 

elsif ( gen_en == 0) then 



// buffer is close 



ready = 0 
datapath controller 
else 



// stalled by the 



5 



ready = 1 
no stall 



// everything good 



32.9. 10.2 Data generator 

1 0 The data generator block reads data from the dot buffer and feeds dot data to the printhead at a 
configured rate (set by the Printhead Rate). It also generates the margin zero data and aligns the 
dot data generation to the synchronization pulse from the PHI controller. 

The data generator controller waits in Reset state until it receives a line start pulse from the PHI 
controller (data_$t signal). Once a start pulse is received it proceeds to the SrclkPre state loading 

15 a counter with the SrclkPre value. While in this state it decrements the counter. No data is read or 
output at this stage. When the count is zero the machine proceeds to the DataGenl state. 
On transition it loads the counter with the printhead size (print_head_size). If margining is to be 
used then the configured print_head_size should be adjusted by the dot margin value i.e. 
phnt_head_size = (physicaLprint_head_size - (dot_margin * 2)). 

20 Dot data is transferred to the printhead serializer in dot-pairs, with one dot-pair transferred every 3 
pclk cycles. To construct a dot data pair the state machine reads one dot in the DataGenl state, 
one dot in the DataGen2 state and waits for one clock cycle in the DataGen3 while the data is 
transferred to the data serializer. The counter will decrement for every dot data word transferred. 
The exact data rate is dictated by the dot buffer fill levels and the configured printhead rate 

25 (PrintheadRate). When in DataGen3 state the machine determines if it should waits for 3 cycles or 
transfer another dot pair to the data serializer. The generator determines the rate by comparing 
the rate counter (rate_cnt) with the configured PrintheadRate value. If the bit selected by the 
rate_cnt in the print_head_rate bus is one data is transferred, otherwise the 3 cycles are skipped 
(Waitl, Wait2 and Wait3). If the PrintHeadRate is set to all zeros then no data will ever get 

30 transferred. The rate counter is decremented (rate_cnt) while in the DataGen2 and Wait2 states. 
The rate counter is allowed to wrap normally. 

The pseudo-code for the rate control DataGen3 (or Wait3) state is given by: 



// decrement the rate count 



rate cnt 



// happens in DataGen2, or 



35 



Wait2 

// determine if data should be read 

// first determine if data is available in buffer 

if (rd adr != wr_adr ) then 



40 



if (print_head_rate [rate_cnt] == 1 ) then 
dot_active = 1 
gate_srclk = 1 
count - - 



next state = DataGenl 
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else 

dot_active = 0 
gate_srclk = 0 
next__state = Waitl 

5 else 

dot_active = 0 
gate_srclk = 0 
next_state = Waitl 
When the dot counter reaches zero the state machine will jump to the MarginGenl state if the 
1 0 configured margin value is non-zero, otherwise it will jump directly to the SrclkPost state. On 

transition to MarginGenl state it loads the cycle counter with the dot_margin value, and begins to 
count down. While in the MarginGenl, MarginGen2 and MarginGen3 state machine loop the data 
generator logic block writes dot data to the printhead but does not read from the dot buffers. It 
creates zero dot data words for the margin duration. As with normal dot data, it creates one dot in 
1 5 MarginGenl and MarginGen2 states, then wait a clock cycle to allow the transfer to the data 
serializer to complete. 

When the counter reaches zero the machine jumps to the SrclkPost state, loads the clock counter 
with the SrclkPost value and decrements. When the count is finished the state machine returns to 
the Reset and awaits the next start pulse. Should a line sync arrive before the data generators 
20 have completed (datajin signal) the PHI controller will detect a print error and stall the PHI 
interface. 

As a consequence of the data transfer mechanism of dot pair cycles followed by a wait state, the 
printhead size (print_head_size) and dot margin (dot_margin) must always be even dot values. 
32. 9.10.3 Data serializer 

25 The data serializer block converts 12-bit dot data at pclk rates (nominally 160 MHz) to 2-bit data at 
doclk rates (nominally 320 MHz). 

The srclk is only active when data is available for transfer to the printhead, as enabled by the 
gate_srclk signal. The data rate mechanism in the data generator block will mean that data is not 
transferred to the printhead on every set of 3 pclk cycles. Both the dot_data and gate_srclk 

30 signals are controlled by the data generator block and can only change on a fixed 3 pclk cycle 

boundary. Data is transferred to the printhead on both edges of srclk (i.e double data rate DDR). 
Directly after a line sync pulse the mux control logic and the srclk generation logic are reset to a 
known state (the srclk is set high). Before data can begin transfer to the printhead it must 
generate a line setup edge on srclk, causing srclk to go low. The line setup edge happens 

35 SrclkPre number of pclk cycles after the line sync falling edge (indicated by the srjnit signal from 
the data generator block). 

All data transfers to the printhead will be in groups of 6 2-bit data words, each word clocked on an 
edge of srclk. For each group srclk will start low and end low. 

At the end of a full line of data transfer the srclk must generate a line complete edge to return the 
40 srclk to a high state before the next line sync pulse. The data generator block generates a sr_com 
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signal to indicate that* the data transfer to the printhead has completed and that the line complete 
edge can be inserted. The sr_com signal is generated before the SrClkPost period. 
The data serializer block allows easy separation of clock gating and clock to logic structures from 
the rest of the PHI interface. 
5 The mux logic determines which data bits from the dot_data bus should be selected for output on 
the ph_data bus to the printhead. The mux selector is initialized by an edge detect on the srjnit 
signal from the data generator. 

// determine wrap and init points 
if (phi_serial_order == 1) then 
10 mux_wrap = 5 

mux_ini t = 0 
else 

mux_wrap = 0 
mux_init = 5 
15 // the mux selector logic 

if ( (sr_init_edge == 1 ) OR ( mux_sel == mux_wrap )) then 

mux_sel = mux_init 
elsif ( phi_serial_order == 1 ) then 

mux_sel - - // decrement order 

20 else 

mux_sel++ // increment order 

The dot data serialization order can be configured by Ph/SerialOrder register. If the 
PhiSerialOrder is zero the order is dot[1:0], then dot[3:2] then dot[5:4]. If the register is one then 
25 the order is dot[5:4], dot[3:2], dot[1:0]. 

The srclk control logic is initialized to 1 when a line_st positive edge is detected. If either 
sr_com_edge, srjnit_edge or gate_src/k are equal to one srclk is transitioned, srclk is always 
clocked out to the output pins on the negative edge of doclk to place the clock edge in the centre 
of the data. 

30 T he pseudo code for the control logic is: 

if (line_st_edge ==1 ) then 
srclk_gen = 1 

elsif ( (gate_srclk ==1) OR (sr_init_edge==l) OR 
(sr_com_edge==l ) ) then 
35 srclk_gen = ~srclk_gen 

else 

// hold 

33 Package and Test 
40 Test Units 

33.1 JTAG INTERFACE 
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A standard JTAG (Joint Test Action Group) Interface is included in SoPEC for Bonding and IO 
testing purposes. The JTAG port will provide access to all internal BIST (Built In Self Test) 
structures. 

33.2 Scan Test I/O 

5 The SoPEC device will require several test lO's for running scan tests. In general scan in and 
scan out pins will be multiplexed with functional pins. 

33.3 Analog Test Units 

33.3.1 USB PHY Testing 

The USB phy analog macro, will contain built-in in test structure, which can be access by either 
1 0 the CPU or through the JTAG port. 

33.3.2 Embedded PLL Testing 

The embedded clock generator PLL will require test access from JTAG port. 
34 SoPEC Pinning and Package 
34.1 Overview 

15 It is intended that the SoPEC package be a 100 pin LQFP. Any spare pins in the package may be 
used by increasing the number of available GPIO pins or adding extra power and ground pin. The 
pin list shows the minimum pin requirement for the SoPEC device. 
Table 217. SoPEC Pin List (100 LQFP) 



Group 


Pin Name 


#pin s 


Dir 


Type 


Volt 


I/O Rate 
(S/D) 


Freq 
(Mh 
z) 


Description 


IO Cell Type 


Test 

Function 


Test 

Macro 

Function 


Clocks and resets 




Group 1 


Xtalin 


1 


I 




N/A 


N/A 


32 


Crystal 
Input pin 


AINSA_PM_ 

A ' 


None 






Xtalout 


1 


O 




N/A 


N/A 


32 


Crystal 
output pin 


ABNSTJPM 
_A 


None 




Group 2 


reset_n 


1 


I 


LVTT 
L 


3.3v 


s 


10 


Asynchron 
ous active 
low reset 


IT33LTPUT_ 
PM_A 


LT (leakage 
test) 




PrintHead Interface 




Group 3 


phead_dat 
a 


8 


O 


LVDS 


1.5v 


d 


160 


Print head 
data 


OLVDS15_P 
M_A 


None 






Srclk 


4 


o 


LVDS 


1.5v 


d 


160 


Print head 
clock 


OLVDS15_P 
M_A 


None 




Group 4 


Readl 


1 


o 


LVTT 
L 


3.3v 


s 


160 


Common 
Print head 
mode 
control 


BT3365T_P 
M_A 


A_Clock 
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Frclk 


1 


I/O 


LVTT 
L 


3.3v 


s 


160 


Common 
Fire pattern 
shift clock, 
needs to 
toggle once 
per fire 
cycle 


BT3365TJ> 
M_A 


B_Clock 




phi_spare 


1 


I/O 


LVTT 
L 


3.3v 


s 


160 


PHI spare 
pin (old 
profile pin) 


BT3365T_P 
M_A 


C_Clockl 




Lsyncl 


1 


I/O 


LVTT 
L 


3.3v 


s 


160 


Line Sync 
output from 
Master to 
Slaves 


BT3365T_P 
M_A 


C_Clock2 




USB Connections 


Group 5 


Usb_host 
d 


2 


I/O 


Differ 
ential 


3.3v 


s 


12 


USB 

differential 
data for 
host 


BUSB2_PM_ 
A 


None 






Usb_devd 


2 


I/O 


Differ 
ential 


3.3v 


s 


12 


USB 

differential 
data for 
device 


BUSB2_PM_ 
A 


None 




Group 6 


usbd_vbu 
s_sense 


1 


I 


LVTT 
L 


3.3v 


s 


10 


USB device 
VBUS 
power 
sense 


BT3365T_P 
M_C 


1 scan out 






usbd_pull 
_up_en 


1 


o 


LVTT 
L 


3.3v 


s 


10 


USB device 
termination 
enable 


BT3365T_P 
M_C 


1 scan out 




JTAG 




Group 7 


Tdo 


1 


o 


LVTT 
L 


3.3v 


s 


10 


JTAG Test 
data out 
port 


BT3365T_P 
M_A 


C_Clock3 






Tms 


1 


I 


LVTT 
L 


3.3v 


s 


10 


JTAG Test 
mode select 


IT33RIT_PM 
_A 


RI 




Tdi 


1 


I 


LVTT 
L 


3.3v 


s 


10 


JTAG Test 
data in port 


IT33D1PUT_ 
PM_A 


DI1 




Tck 


1 


I 


LVTT 


3.3v 


s 


10 


JTAG Test 


IT33D2PUT_ 


DI2 
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L 








access port 
clock 


PM_A 






General Purpose IO 


Group 8 


Gpio[3:0] 


4 


I/O 


LVTT 
L 


3.3v 


s 


32 


ISI 

interface 
pins / GPIO 


BT3335PUT 
_PM_B 


4 Scanin 




Group 9 


Gpio[7:4] 


4 


I/O 


High 
Drive 
LVTT 
L 


3.3v 


s 


32 


LED driver 

pins / 

general 

purpose 

Input/Outp 

ut 


BT3365T.P 
MJC 


4 Scanin 


PCNT 
PROGSR 
OM OSC 


Group 
10 


Gpio[19:8 
] 


12 


I/O 


LVTT 
L 


3.3v 


s 


32 


General 
purpose 
Input/Outp 
ut 


BT3365PUT 
_PM_B 


2 Scanin 10 
Scanout 


DIAGOU 

T(aka 

MRSTRO 

) 


Group 
11 


Gpio[22:2 
0] 


3 


I/O 


LVTT 
L 


3.3v 


s 


32 


General 
purpose 
Input/Outp 
ut 


BT3365PUT 
_PM_B 


CE0_Scan 

TESTM3 

TSTN1 




Group 
12 


Gpio[31:2 
3] 


10 


I/O 


LVTT 
L 


3.3v 


s 


32 


Functional 
Spare IOs 
required for 
scan test 


BT3365T_P 
M_C 


6 Scanin 4 
scanout 




Analog Power IO 




Group 
13 


agnd 


1 


I 


Power 


N/A 


N/A 


N/A 


PLL analog 
gnd 


AINSD3.PM 
_A 


None 






avdd 


1 


I 


Power 


N/A 


N/A 


N/A 


PLL analog 
vdd 


AINSD3_PM 
_A 


None 




agnd 


1 


I 


Power 


N/A 


N/A 


N/A 


Oscillator 
analog gnd 


AJNSD_PM_ 
A 


None 




avdd 


1 


I 


Power 


N/A 


N/A 


N/A 


Oscillator 
analog vdd 


AINSD_PM_ 
A 


None 




Test Only Pin 




Group 
14 


TE 


1 


I 


CMO 
S 


1.5 v 


N/A 


N/A 


Test Enable 


IC15TEPDT 
_PM__A 


Test only 






VPP 


1 


I 


CMO 
S 


L5v 


N/A 


N/A 


Fat Wire 

Analog 

Receiver/D 


DRAMVPP_ 
PM 


Test only 
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river for 

Embedded 

DRAM 

Analog 

Inputs 








VWP 


1 


I 


CMO 
S 


1.5v 


N/A 


N/A 


Fat Wire 

Analog 

Receiver/D 

river for 

Embedded 

DRAM 

Analog 

Inputs 


DRAMVWP 
_PM 


Test only 




VREFX 


1 | 


I 


CMO 
S 


1.5v 


N/A 


N/A 


Fat Wire 

Analog 

Receiver/D 

river for 

Embedded 

DRAM 

Analog 

Inputs 


DRAMVREF 
X_PM 


Test only 




DLT 


1 


I 


CMO 

s 


1.5v 


N/A 


N/A 


DRAM 
Iddq lest 


IC15DLTPU 


Test only 




MC 


1 


I 


CMO 
S 


1.5v 


N/A 


N/A 


IO Mode 
Control 


IC15MCT_P 
M_A 


Test only 




DRAM_E 
N 


1 


I 


CMO 

S. 


1.5v 


N/A 


N/A 


DRAM 
Enable(EN) 


IC15LTPUT 
_PM_A 


Test only 




Total Signal Pins 


73 


Functional pin count is 62 


Test IO count 5 1 




Power Only Pins 




Group 
15 


Gnd 


8 


I 


Power 


N/A 


N/A 


N/A 


gnd 


GND_PM_A 


None 






Vdd 


4 


I 


Power 


N/A 


N/A 


N/A 


vdd L5v, 

core 

voltage 


VDD150_P 
M_A 


None 




vdd330 


4 


I 


Power 


N/A 


N/A 


N/A 


vdd 3.3v, 
IO voltage 


VDD330__P 
M_A 


None 




Group 
15 


vdd/gnd 


11 


I 


Power 


N/A 


N/A 


N/A 


Power pin 
fill, 

GND. Vdd 1 


GND_PM_A 

f 

VDD150.P 


None 
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.5,Vdd3.3 
as required 


M_A/ 

VDD330_P 
M_A 






Total Pins 


100 
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Please note that pages 549 to 554 are intentionally missing. 
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BILITHIC PRINTHEADS 
1 Background 

Silverbrook's bilithic Memjet™ printheads are the target printheads for printing systems which will 
be controlled by SoPEC and MoPEC devices. 
5 This document presents the format and structure of these printheads, and describes the their 
possible arrangements in the target systems. It also defines a set of terms used to differentiate 
between the types of printheads and the systems which use them. 

Bilithic Printhead Configurations 
10 2 Definitions 

This document presents terminology and definitions used to describe the bilithic printhead systems. 
These terms and definitions are as follows: 

° Printhead Type - There are 3 parameters which define the type of printhead used in a 
system: 

15 o Direction of the data flow through the printhead (clockwise or anti-clockwise, with the 
printhead shooting ink down onto the page), 
o Location of the left-most dot (upper row or lower row, with respect to V+ f ). 
o Printhead footprint (type A or type B, characterized by the data pin being on the left or the 
right of V +t where V/+ is at the top of the printhead). 
20 © Printhead Arrangement - Even though there are 8 printhead types, each arrangement has to 
use a specific pairing of printheads, as discussed in Section 3. This gives 4 pairs of 
printheads. However, because the paper can flow in either direction with respect to the 
printheads, there are a total of eight possible arrangements, e.g. Arrangement 1 has a Type 0 
printhead on the left with respect to the paper flow, and a Type 1 printhead on the right. 
25 Arrangement 2 uses the same printhead pair as Arrangement 1 , but the paper flows in the 

opposite direction, 
o Color 0 is always the first color plane encountered by the paper, 
o Dot 0 is defined as the nozzle which can print a dot in the left-most side of the page. 
° The Even Plane of a color corresponds to the row of nozzles that prints dot 0. 
30 Note that in all of the relevant drawings, printheads should be interpreted as shooting ink down onto 
the page. 

Figure 295 shows the 8 different possible printhead types. Type 0 is identical to the Right Printhead 
presented in Figure 297 in [1], and Type 1 is the same as the Left Printhead as defined in [1]. 

35 
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While the printheads shown in Figure 295 look to be of equal width (having the same number of 
nozzles) it is important to remember that in a typical system, a pair of unequal sized printheads may 
be used. 

2.1 Combining Bilithic Printheads 
5 Although the printheads can be physically joined in the manner shown in Figure 296, it is preferable 
to provide an arrangment that allows greater spacing between the 2 printheads will be required for 
two main reasons: 
o inaccuracies in the backetch 

o cheaper manufacturing cost due to decreasing the tolerance requirements in sealing the ink 
1 0 reservoirs behind the printhead 

Failing to account for these inaccuracies and tolerances can lead to misalignment of the nozzle 
rows both vertically and horizontally, as shown in Figure 297. 

An even row of color n on printhead A may be vertically misaligned from the even row of color n on 
1 5 printhead B by some number of dots e.g. in Figure 297 this is shown to be 5 dots. And there can 
also be horizontal misalignment, in that the even row of color n printhead A is not necessarily 
aligned with the even row of color n+1 on printhead A, e.g. in Figure 297 this horizontal 
misalignment is 6 dots. 

20 The resultant conceptual printhead definition, shown in Figure 297 has properties that are 
appropriately parameterized in SoPEC and MoPEC to cater for this class of printheads. 

The preferred printheads can be characterized by the following features: 

o All nozzle rows are the same length (although may be horizontally displaced some number of 
25 dots even within a color on a single printhead) 

o The nozzles for color n printhead A may not be printing on the same line of the page as the 
nozzles for color n printhead B. In the example shown in Figure 297, there is a 5 dot 
displacement between adjacent rows of the printheads. 
o The exact shape of the join is an arbitrary shape although is most likely to be sloping (if 
30 sloping, it could be sloping either direction) 

o The maximum slope is 2 dots per row of nozzles 

o Although shift registers are provided in the printhead at the 2 sides of the joined printhead, 
they do not drive nozzles - this means the printable area is less than the actual shift registers, 
as highlighted by Figure 298. 
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2.2 Printhead Arrangements 

Table 218 defines the printhead pairing and location of the each printhead type, with respect to the 
flow of paper, for the 8 possible arrangements 



Printhead Arrangement 


Printhead on left side, 


Printhead on right side, 




with respect to the flow 


with respect to the flow of 




ot paper 


paper 


Arrangement 1 


Type 0 


Type 1 


Arrangement 2 


Type 1 


Type 0 


Arrangement 3 


Type 2 


Type 3 


Arrangement 4 


Type 3 


Type 2 


Arrangement 5 


Type 4 


Type 5 


Arrangement 6 


Type 5 


Type 4 


Arrangement 7 


Type 6 


Type 7 


Arrangement 8 


Type 7 


Type 6 



5 ~ ~ ^ 

3 Bilithic Printhead Systems 

When using the bilithic printheads, the position of the power/gnd bars coupled with the physical 
footprint of the printheads mean that we must use a specific pairing of printheads together for 
printing on the same side of an A4 (or wider) page, e.g. we must always use a Type 0 printhead 
1 0 with a Type 1 printhead etc. 

While a given printing system can use any one of the eight possible arrangements of printheads, 
this document only presents two of them, Arrangement 1 and Arrangement 2, for purposes of 
illustration. These two arrangements are discussed in subsequent sections of this document. 
1 5 However, the other 6 possibilities also need to be considered. 

The main difference between the two printhead arrangements discussed in this document is the 
direction of the paper flow. Because of this, the dot data has to be loaded differently in Arrangement 
1 compared to Arrangement 2, in order to render the page correctly. 

20 

3.1 Example 1 : Printhead Arrangement 1 

Figure 299 shows an Arrangement 1 printing setup, where the bilithic printheads are arranged as 
follows: 

o The Type 0 printhead is on the left with respect to the direction of the paper flow. 
25 o The Type 1 printhead is on the right. 
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Table 219 lists the order in which the dot data needs to be loaded into the above printhead system, 
to ensure color O-dot 0 appears on the left side of the printed page. 

Table 219. Order in which the even and odd dots are loaded for printhead 

Arrangement 1 

5 



Dot Sense 


Type 0 printhead 
when on the left 


Type 1 printhead 
when on the right 


Odd 


Loaded second in 
descending order. 


Loaded first in 
descending order. 


Even 


Loaded first in 
ascending order. 


Loaded second in 
ascending order. 



Figure 300 shows how the dot data is demultiplexed within the printheads. 

Figure 301 and Figure 302 show the way in which the dot data needs to be loaded into the print- 
1 0 heads in Arrangement 1 , to ensure that color 0-dot 0 appears on the left side of the printed page. 
Note that no data is transferred to the printheads on the first and last edges of SrClk. 

3.2 Example 2: Printhead Arrangement 2 

Figure 303 shows an Arrangement 2 printing setup, where the bilithic printheads are arranged as 
1 5 follows: 

o The Type 1 printhead is on the left with respect to the direction of the paper flow, 
o The Type 0 printhead is on the right. 

Table 220 lists the order in which the dot data needs to be loaded into the above printhead system, 
to ensure color 0-dot 0 appears on the left side of the printed page. 
20 Table 220. Order in which the even and odd dots are loaded for printhead 

Arrangement 2 



Dot Sense 


Type 0 printhead 
when on the right 


Type 1 printhead 
when on the left 


Odd 


Loaded first in 
descending order. 


Loaded second in 
descending order. 


Even 


Loaded second in 
ascending order. 


Loaded first in 
ascending order. 



Figure 304 shows how the dot data is demultiplexed within the printheads. 
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Figure 305 and Figure 306 show the way in which the dot data needs to be loaded into the 
printheads in Arrangement 2, to ensure that color 0-dot 0 appears on the left side of the printed 
page. 

5 Note that no data is transferred to the printheads on the first and last edges of SrClk. 
4 Conclusions 

Comparing the signalling diagrams for Arrangement 1 with those shown for Arrangement 2, it can 
be seen that the color/dot sequence output for a printhead type in Arrangement 1 is the reverse of 
1 0 the sequence for same printhead in Arrangement 2 in terms of the order in which the color plane 
data is output, as well as whether even or odd data is output first. However, the order within a color 
plane remains the same, i.e. odd descending, even ascending. 

From Figure 307 and Table 221 , it can be seen that the plane which has to be loaded first (i.e. even 
15 or odd) depends on the arrangement. Also, the order in which the dots have to be loaded (e.g. even 
ascending or descending etc.) is dependent on the arrangement. 

As well as having a mechanism to cope with the shape of the join between the printheads, as 
discussed in Section 2.1 , if the device controlling the printheads can re-order the bits according to 
20 the following criteria, then it should be able to operate in all the possible printhead arrangements: 
o Be able to output the even or odd plane first. 

o Be able to output even and odd planes in either ascending or descending order, inde- 
pendently. 

o Be able to reverse the sequence in which the color planes of a single dot are output to the 
25 printhead. 

Table 221. Order in which even and odd dots and planes are loaded into the various 
printhead arrangements 



Printhead 
Arrangement 


Left side of printed page 


Right side of printed page 


Arrangement 1 


Even ascending loaded first 
Odd descending loaded 
second 


Odd descending loaded first 
Even ascending loaded 
second 


Arrangement 2 


Odd descending loaded first 
Even ascending loaded 
second 


Even ascending loaded first 
Odd descending loaded 
second 


Arrangement 3 


Odd ascending loaded first 


Even descending loaded 
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Even descending loaded 
second 


first 

Odd ascending loaded 
second 


Arrangement 4 


Even descending loaded 
first 

Odd ascending loaded 
second 


Odd ascending loaded first 
Even descending loaded 
second 


Arrangement 5 


Odd ascending loaded first 
Even descending loaded 
second 


Even descending loaded 
first 

Odd ascending loaded 
second 


Arrangement 6 


Even descending loaded 
first 

Odd ascending loaded 
second 


Odd ascending loaded first 
Even descending loaded 
second 


Arrangement 7 


Even ascending loaded first 
Odd descending loaded 
second 


Odd descending loaded first 
Even ascending loaded 
second 


Arrangement 8 


Odd descending loaded first 
Even ascending loaded 
second 


Even ascending loaded first 
Odd descending loaded 
second 
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CMOS SUPPORT ON BILITHIC PRINTHEAD 
1 Basic Requirements 

To create a two part printhead, of A4/Letter portrait width to print a page in 2 seconds. Matching 
Left/Right chips can be of different lengths to make up this length facilitating increased wafer usage. 
5 the left and right chips are to be imaged on an 8 inch wafer by "Stitching" reticle images. 

The memjet nozzles have a horizontal pitch of 32 urn, two rows of nozzles are used for a single 
colour. These rows have a horizontal offset of 16 urn. This gives an effective dot pitch of 16 urn, or 
62.5 dots per mm, or 1587.5 dots per inch, close enough to market as 1600 dpi. 
The first nozzle of the right chip should have a 32 urn horizontal offset from the final nozzle of the 
1 0 left chip for the same color row. There is no ink nozzle overlap (of the same colour) scheme 
employed. 

1.1 Power Supply 

Vdd/Vpos and Ground supply is made through 30 urn wide pads along the length of the chip using 
1 5 conductive adhesive to bus bar beside the chips. Vdd/Vpos is 3.3 Volts. (12V was considered for 

Vpos but routing of CMOS Vdd at 3.3V would be a problem over the length of the chips, but this will 
be revisited). 

1.2 MEMS CELLS 

20 The preferred memjet device requires 180nJ of energy to fire, with a pulse of current for 1 usee. 
Assuming 95% efficiency, this requires a 55 ohm actuator drawing 57.4 mA during this pulse. 

1.2.1 ISSUE!!! 

For 1 pages per 2 second, or -300 mm * 62.5 (dots/mm) / 2 sec ~= 10 kHz or 100 usee per line. 
25 With 1 usee fire pulse cycle, every 100th nozzle needs to fire at the same time. We have 13824 
nozzles across the page, so we fire 1 38 nozzles at a time. 

1 .2.2 64um unit cell height 

This cell would have 4 line spacing between the odd and even dots, and 8 line spacing between 
30 adjacent colours. 

1 .2.3 80 urn unit cell height 

This cell would have 5 line spacing between the odd and even dots, and 10 line spacing between 
adjacent colours. 

35 
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1.3 Versions 

1 .3.1 6 Colour 1600 dpi with 64 urn unit cell 
Left and Right Chip. 

5 1 .3.2 6 Colour 1 600 dpi with 80 urn unit cell 
Left and Right Chip. 

1 .3.3 4 Colour 800 dpi with 80 urn unit cell 

For camera application. Single nozzle row per colour. 

10 

1.4 Air Supply 

Air must be supplied to the MEMS region through holes in the chip. 
2 Head Sizes 

1 5 The combined heads have 13824 nozzles per colour totalling 221 .184mm of print area. Enough to 
provide full breadth for A4 (210 mm) and Letter (8.5 inch or 21 5.9 mm). 

Table 1 . Head Combinations 



Left Head 


Right Head 


Stitch Parts 


Nozzles per Colour 


Stitch Parts 


Nozzles per Colour 


8 


11160 


2 


2664 


7 


9744 


3 


4080 


6 


8328 


4 


5496 


5 


6912 


5 


6912 


4 


5496 


6 


8328 


3 


4080 


7 


9744 


2 


2664 


8 


11160 



20 Nozzles per Colour is calculated as (("Stitch Parts" -1)*1 18+104)*12. Nozzles per row is half this 
value. Most likely the 8:2 head set will not be manufactured. The preferred wafer layout, manages 
to avoid this set, without any loses. 

3 Interface 

25 Each print head has the same I/O signals (but the Left and Right versions might have a different pin 
out). 
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Table 2. I/O pins 



Name 


I/O 


Function 


Common 


Max 

Speed 

(MHz) 


Data [0-1] 


I 


Dot data for colours 0-5, using Differential 
Signalling (DataL the complementary signal), 
colours[0-2] on Data[0], colour[3-5] on Data[1] 


No 


320 


DataL[0'1] 


I 


complementary signal of Data[0-1] 






SrClk 


I 


Dot data shift clock using Differential Signalling 
(SrClkL the complementary signal) 


No 


320 


SrClkL 


I 


complementary signal of SrClk 






ReadL 


I 


FrClk, Pr, LSyncL output mode if signal mode 
bit is set 


Yes 


1 




i 


Fire pattern shift clock 


Yes 


1 




o 


nozzle test result (mode = 0b001 ), LsyncL = 0 
CMOS testing (mode = 0b1 1 1 ), LsyncL = 1 


Yes* 




Pr 


I 


Pulse Profile for all colours 


Yes 


1 3 




o 


Temperature Output (mode = 0b010), LsyncL = 
0 

CMOS testing (mode = 0b1 1 1 ), LsyncL = 1 


Yes D 




LsyncL 


I 


0 - Capture dot data for next print line 


Yes 






o 


CMOS testing (mode = 0b1 1 1 ) t LsyncL = 1 


Yes D 





Pins marked as common can be controlled by the same signal from the controller (SOPEC). 
3.1 Dot firing 

To fire a nozzle, three signals are needed. A dot data, a fire signal, and a profile signal. When all 
signals are high, the nozzle will fire. 



Functionally could be common, but for timing/electrical reasons should run point to point. 
Can be shared if one side has mode=0b000 

1 MHz cyde, but the resolution of the mark/space ratio may require 50 ns. 
10 kHz cycle, with minimum low pulse of 10 ns (no maximum). 
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The dot data is provide to the chip through a dot shift register with input Data[x], and clocked into 
the chip with SrClk. The dot data is multiplex on to the Data signals, as Dot[0-2] on Data[0], and 
Dot[3-5] on Data[2]. After the dots are shifted into the dot shift register, this data is transfer into the 
dot latch, with a low pulse in LsyncL. The value in the dot latch forms the dot data used to fire the 
5 nozzle. The use of the dot latch allows the next line of data to be loaded into the dot shift register, at 
the same time the dot pattern in the dot latch is been fired. 

Across the top of a column of nozzles, containing 12 nozzles, 2 of each colour (odd and even dots, 
4 or 5 lines apart), is two fire register bits and a select register bit. The fire registers forms the fire 
1 0 shift register that runs length of the chip and back again with one register bit in each direction flow. 
The select register forms the Select Shift Register that runs the length of the chip. The select 
register, selects which of the two fire registers is used to enables this column. A '0' in this register 
selects the forward direction fire register, and a '1 ' selects the reverse direction fire register. This 
output of this block provides the fire signal for the column. 

15 

The third signal needed, the profile, is provide for all colours with input Pr across the whole colour 
row at the same time (with a slight propagation delay per column). 

3.2 Dot Shift Register Orientation 
20 The left side print head (chip) and the right side print head that form complete bi-lithic print head, 
have different nozzle arrangement with respect to the dot order mapping of the dot shift register to 
the dot position on the page. 

With this mapping, the following data streams will need to provided. 



Left Head 


Right Head 


Size 


n-m 


dot order 


m 




7:3 


97 44 


[13822,13820,138 18,...,4084,4082,4080,] line y+5 
[4081,4083,4085,...,13819,13821, 13823] liney 


40 80 


[1,3,5,...,4075,4077,4079,] line y 
[4078,4076,4074,...,4,2,0] line y+5 


6:4 


83 28 


[13822,13820,13818,...,5500,5498,5496 s ] line y+5 
[5497,5499,5501,...,13819,13821, 13823] line y 


54 96 


[1,3,5,...,549 1,5493,5495,] line y 
[5494,5492,5490,.. .,4,2,0] line y+5 


5:5 


69 12 


[13822,13820,13818,...,6916,6914,6912 5 ] line y+5 
[6913,6915,6917,...,13819,13821, 13823] line y 


69 12 


[1,3,5,...,6907,6909,6911,] line y 
[6910,6908,6906,...,4,2,0] line y+5 


4:6 


54 96 


[13822,13820,13818,...,8332,8330,8328,] line y+5 
[8329,8331,8333,.. M 13819,13821, 13823] line y 


83 28 


[1,3,5,...,8323,8325,8327,] liney 
[8326,8324,8322,...,4,2,0] line y+5 


3:7 


40 80 


[13822,13820,13818,...,9748,9746,9744,] line y+5 
[9745,97447,9749,...,13819,13821, 13823] line y 


97 44 


[1,3,5,...,9739,9741,9743,] liney 
9742,9740,9738,...,4,2,0] line y+5 
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The data needs to be multiplexed onto the data pins, such that Data[0] has {(CO, C1, C2), (CO, C1, 
C2)....} in the above order, and Data[1] has {(C3, C4, C5), (C3, C4, C5)....}. 

Figure 31 1 shows the timing of data transfer during normal printing mode. Note SrClk has a default 
5 state of high and data is transferred on both edges of SrClk. If there are L nozzles per colour, SrClk 
would have L+2 edges, where the first and last edges do not transfer data. 

Data requires a setup and hold about the both edges of SrClk. Data transfers starts on the first 
rising after LSyncL rising. SrClk default state is high and needs to return to high after the last data of 
1 0 the line. This means the first edge of SrClk (falling) after LSyncL rising, and the last edge of SrClk 
as it returns to the default state, no data is transferred to the print head. LSyncL rising requires 
setup to the first falling SrClk, and must stay high during the entire line data transfer until after last 
rising SrClk. 

1 5 3.3 Fire Shift Register 

The fire shift register controls the rate of nozzle fire. If the register is full of '1 's then the you could 
print the entire print head in a single FrClk cycle, although electrical current limitations will prevent 
this happening in any reasonable implementation. 

20 Ideally, a T is shifted in to the fire shift register, in every /7 th position, and a '0' in all other position. 
In this manner, after n cycles of FrClk, the entire print head will be printed. 

The fire shift register and select shift registers allow the generation of a horizontal print line that on 
close inspection would not have a discontinuity of a "saw tooth" pattern, Figure 312 a) & b) but a 
25 "sharks tooth" pattern of c). 

This is done by firing 2 nozzles in every 2n group of nozzle at the same time starting from the outer 
2 nozzles working towards the centre two (or the starting from the centre, and working towards the 
outer two) at the fire rate controlled by FrClk. 

30 

To achieve this fire pattern the fire shift register and select shift register need to be set up as show 
in Figure 313 . 

The pattern has shifted a f 1 ' into the fire shift register every n m positions (where n is usually is a 
35 minimum of about 100) and n '1 's, followed n '0's in the select shift register. At a start of a print 
cycle, these patterns need to be aligned as above, with the "1000..." of a forward half of fire shift 
register, matching an n grouping of T or '0's in the select shift register. As well, with the "1000..." of 
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a reverse half of the fire shift register, matching an n grouping of T or 'O's in the select shift register. 
And to continue this print pattern across the butt ends of the chips, the select shift register in each 
should end with a complete block of n Ts (or 'O's). 

5 Since the two chips can be of different lengths, initialisation of these patterns is an issue. This is 
solved by building initialisation circuitry into chips. This circuit is controlled by two registers, nlen(14) 
and count(14) and b(1 ). These registers are loaded serially through Data[0], while LSyncL is low, 
and ReadL is high with FrClk. 

10 The scan order from input is b, n[13-0],c[0-13],color[5-0], mode[2-0] therefore b is shifted in last. 

The system color and mode registers are unrelated to the Fire Shift Register, but are loaded at the 
same time as this block. There function is described later. 

Table 4. Head Combinations Initialisation for n=100 



Nozzle s 
L B 


Nozzle s 
La 


nlen (A &B) - 
n-1 


count A = 
(L A /2) mod n 
-1 


b A 


be 


rem= 

(Lb/2) mod n 


counts = 

(L A -L B +rem) mod n 
-1 


4080 


9744 


99 


71 


0 


0 


40 


3 


5496 


8328 


99 


63 


0 


0 


48 


79 


6912 


6912 


99 


55 


0 


0 


56 


55 



15 

The following table shows the values to programme the bi-lithic head pairs using a fire pattern 
length of 100. The calculation assumes head 'A' is the longest head of the pair and once the 
registers are initialised with LA FrClk cycles (ReadL='0\ LSyncL='1'). rem would be the correct 
value for counts if chip B was only clocked (FrClk) L B times. But this chip will be over clocked L A -L B 
20 cycles. The values of b A and b B are either the same or inverse of each other. The actually value 

does not matter. They need to be different from each other if the select shift registers would end up 
with different values at the butt ends. If (L A /2n) is even (and counU is non zero), then the final run in 
TVs select shift register will be !b A . If (L a -I_b/2) mod n is even (and counts is non zero) then the final 
run in 'B's select shift register will be !b B . 

25 
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3.4 System Registers 

As describe above, the Fire Shift Register generation block, also contains some system registers. 

Table 5. System Registers 



Name 


Size 


Function 


Color | 


6 


Each bit is an enable for the corresponding colour. 
If color[X]=0, then Pr x is 0 and SrClk x is 0. 
If color[X]=1 , then Pr x follows the Pr signal and 
SrClk x is deserialised SrClk. 


Mode 


3 


Mode[0] = 1 , then FrClk pin is used as an output, 

internally the FrClk signal is set to 0 

Mode[1] = 1 , then Pr pin is used as an output, 

internally the Pr signal is set to 0 

Mode[2] = 1 , then LsyncL pin is used as an output, 

nternally the LsyncL signal is set to 1 



3.5 Profile Pattern 

A profile pattern is repeated at FrClk rate. It is expected to be a single pulse about 1us long. But it 
could be a more complicated series of pulse. The actual pattern depends on the ink type. 
The following figure show the external timing to print a line of data. In this example the line is printed 
10 in 8 cycles of FrClk. 

3.6 Interface Modes 

The print head has eight different modes controlled by signals ReadL and LSyncL and system 
mode register. As seen in Figure 318 with both LSyncL and ReadL high, the chip in normal 
1 5 printing mode. Some of these modes can operate at the same time, but may interfere with the result 
of the other modes. 

Table 6. Print Head Modes 



ReadL 


LSyncL 


Function 


Mode 
Registe r 


Internal Mapping 


1 


1 


Normal Print Mode 


000 (XXX) 


SrClk=SrClk/3 

frclk=FrClk 

SelClk=0 

FsClk=FrClk 

Scan=0 

CoreScan=0 
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X 


0 


Dot Load Mode 

© Dot latches are open, loaded with Dot shift 
registers, latch once LSyncL returns to 1 
(this happens regardless of ReadL) 

o Enables Dot Shift register to capture fire 
result. 


000 (XXX) 




1 


0 


Fire Load Mode 
o Data[0] will shift through mode, color, nlen, 
count and b with FrClk 


000 (XXX) 


SrClk=X 

frclk=X 

SelClk=X 

FsClk=FrClk 

Scan=1 

CoreScan=X 


0 


1 


Reset Nozzle Test 
o Resets the state of nozzle test circuit 


001 


SrClk=SrClk 

FrClk=FrClk 

SelClk=FrClk 

FsClk=FrClk 

Scan=0 

CoreScan=1 


0 


1 


CMOS testing mode 
o The contents of the dot shift registers are 
serial shifted out on LsyncL (colourO-1 ), 
FrClk (colour2-3), Pr (colour4-5) with SrClk 


111 




0 


1 


Fire Initialise mode 
o The contents of the fire shift register and 
select shift register is generated with FrClk 


000 (XX0) 




0 


0 


Temperature Output 
o The series of Sigma Delta output are 
clocked out on Pr with FrClk. The sum of 
these bits represent the temperature of the 
chip. 


010 


SrClk=X 

frclk=0 

SelClk=0 

FsClk=0 

Scan=0 

CoreScan=X 


0 


0 


Nozzle Test Output 
o The result of a nozzle test is output on 
FrClk. 


001 





3.6.1 Printing 
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Figure 318 shows show timing for normal printing. During this action, we drop out of Normal Print 
Mode, to Dot Load Mode between line transfers. For printing to perform correctly, all other signals 
should be stable. 

5 3.6.2 Initialising for Printing 

To initialise for printing the fire shift registers and select shift registers need to be setup into a state 
as shown in Figure 318 .To do this the chips are put into Fire Load Mode and the values for nlen, 
count and b are serially shifted from Data[0] clocked by FrClk, As the two chip have separate Data 
line, and common FrClk, this happens at the same time. Once this is done, mode is changed to Fire 
1 0 Initialise Mode, and further L A FrClk cycles are provided to both chips. During all these operation Pr 
should be low, to prevent unintentional firing for nozzles. 

3.6.3 Nozzle Testing 

Nozzle testing is done by firing a single nozzle at a time and monitoring the FrClk pin in the Nozzle 
1 5 Test Output mode. 

Each nozzle has a test switch which closes when the nozzle is fired with an energy level greater 
than required for normal ink ejection. All 12 switches in a nozzle column are connect in parallel to 
the following circuit. 

20 This circuit is initialised when ever LSyncL is high and ReadL is low (Reset Nozzle Test mode). This 
forces all "switch nodes" to low, and the feedback through lower NOR gate will latches this value. 
With LSyncL low and ReadL still low (Nozzle Test Output mode) the Testout of the first nozzle 
column is output on FrClk. If any switch is closed, the switch node of this column will be pulled up, 
and will ripple through to the output as transition from high to low. 

25 

Nozzle testing requires a setup phase in order to fire only one nozzle. There are many ways to 
achieve this. Simplest might be to load a single colour with 101010 through the even nozzles, and 
010101 ... for the odd nozzles (0's for all other colours), and set up a fire pattern with n = L A /2. With 
this fire pattern only one nozzle will fire in each Pr pulse. After firing in Nozzle Test Output mode, a 
30 single FrClk will advance to next nozzle, then Reset and Test. After L A /2 cycles of this testing, a 
single SrClk will advance the dot shift registers to setup the untested nozzles of this colour, and 
another L A /2 cycles of FrClk, Reset and Test will finished testing this colour. Then repeat test 
procedure for other colours. 

35 3.6.4 Temperature Output 

This mode is not well defined yet. In this mode, Pr will output a series of ones and zeros clocked by 
FrClk. After a (currently unknown) number of FrClk cycles the sum of this series will represent the 
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temperature of the chip. Clocking frequency in this mode it expected to be in the range 10kHz - 
1MHz. 

The Frequency of FrClk and the number of cycles need to be programmable. Since this mode 
5 cycles FrClk, the result of fire shift register and select shift register would be changed, but in this 
mode FrClk is disabled to these circuit. So printing can resume without reinitialising. 

3.6.5 CMOS Testing 

CMOS testing is a mode meant for chip testing before MEMS as added to the chip. This mode 
1 0 allows the dot shift register to be shifted out on the LsyncL,FrClk and Pr pins. Much like the nozzle 
test mode, the nozzles are fired while LSyncL is low, but during the firing SrClk will be pulsed, 
loading the dot shift register with the signal that would fire the nozzle. Once captured, the result can 
be shifted out. 

1 5 The Dot Load Mode above violates normal printing procedure by firing the nozzles (Pr) and modify 
the dot shift register (SrClk). 

4 RETICLE LAYOUT 

To make long chips we need to stitch the CMOS (and MEMS) together by overlapping the reticle 
20 stepping field. The reticle will contain two areas: 

The top edge of Area 2, PAD END contains the pads that stitch on bottom edge of Area 1, CORE. 
Area 1 contains the core array of nozzle logic. The top edge of Area 1 will stitch to the bottom edge 
of itself. Finally the bottom edge of Area 2, BUTT END will stitch to the top edge of Area 1. The 
25 BUTT END to used to complete a feedback wiring and seal the chip. 

The above region will then be exposed across a wafer bottom to top. Area 2, Area 7, Area 1 

Area 2. Only the PAD END of Area 2 needs to fit on the wafer. The final exposure of Area 2 only 
requires the BUTT END on the wafer. 

30 

4.1 TSMC U-Frame requirements. 

TSMC will be building us frames 10 mm x 0.23 mm which will be placed either side of both Area 1 
and Area 2. 

35 TSMC requires 6 mm area for blading between the two exposure area. This translates to 3 mm on 
the reticle, as some reticules are 2x size, while most are 5x, the worst case must be used. 
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SECURITY OVERVIEW 



1 Introduction 

A number of hardware, software and protocol solutions to security issues have been 
5 developed. These range from authorization and encryption protocols for enabling secure 
communication between hardware and software modules, to physical and electrical 
systems that protect the integrity of integrated circuits and other hardware. 

It should be understood that in many cases, principles described with reference to 
10 hardware such as integrated circuits (ie, chips) can be implemented wholly or partly in 
software running on, for example, a computer. Mixed systems in which software and 
hardware (and combinations) embody various entities, modules and units can also be 
constructed using may of these principles, particularly in relation to authorization and 
authentication protocols. The particular extent to which the principles described below 
1 5 can be translated to or from hardware or software will be apparent to one skilled in the 
art, and so will not always explicitly be explained. 

It should also be understood that many of the techniques disclosed below have 
application to many fields other than printing. Some specific examples are described 
20 towards the end of this description. 

A M QA Chip" is a quality assurance chip can allows certain security functions and 
protocols to be implemented. The preferred QA Chip is described in some detail later in 
this specification. 

25 

1 .5 QA Chip Terminology 

The Authentication Protocols documents [5] and [6] refer to QA Chips by their function in particular 
protocols: 

o For authenticated reads in [5], ChipR is the QA Chip being read from, and ChipT is the QA 
30 Chip that identifies whether the data read from ChipR can be trusted. ChipR and ChipT are 

referred to as Untrusted QA Device and Trusted QA Device respectively in [6]. 
o For replacement of keys in [5], ChipP is the QA Chip being programmed with the new key, 

and ChipF is the factory QA Chip that generates the message to program the new key. ChipF 
is referred to as the Key Programmer QA Device in [6]. 
35 o For upgrades of data in memory vectors in [5], ChipU is the QA Chip being upgraded, and 
ChipS is the QA Chip that signs the upgrade value. ChipS is referred to as the Value 
Upgrader QA Device and Parameter Upgrader QA Device in [6]. 
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Any given physical OA Chip will contain functionality that allows it to operate as an entity in some 
number of these protocols. 



Therefore, wherever the terms ChipR, ChipT, ChipP, ChipF, ChipU and ChipS are used in this 
5 document, they are referring to logical entities involved in an authentication protocol as defined in 
[5] and [6]. 

Physical QA Chips are referred to by their location. For example, each ink cartridge may contain a 
OA Chip referred to as an INK_QA, with all INK_QA chips being on the same physical bus. In the 
1 0 same way, the QA Chip inside the printer is referred to as PRINTER_QA, and will be on a separate 
bus to the INK_QA chips. 

2 Requirements 
2.1 Security 

1 5 When applied to a printing environment, the functional security requirements for the preferred 
embodiment are: 

© Code of QA chip owner or licensee co-existing safely with code of authorized OEMs 
o Chip owner/licensee operating parameters authentication 
o Parameters authentication for authorized OEMs 
20 o ink usage authentication 

Each of these is outlined in subsequent sections. 

The authentication requirements imply that: 

o OEMs and end-users must not be able to replace or tamper with QA chip 
25 manufacturer/owner's program code or data 

o OEMs and end-users must not be able to perform unauthorized activities for example by 

calling chip manufacturer/owner's code 
o End-users must not be able to replace or tamper with OEM program code or data 
o End-users must not be able to call unauthorized functions within OEM program code 
30 o Manufacturer/owner's development program code must not be capable of running on all 
SoPECs. 

o OEMs must be able to test products at their highest upgradable status, yet not be able to ship 

them outside the terms of their license 
o OEMs and end-users must not be able to directly access the print engine pipeline (PEP) 
35 hardware, the LSS Master (for QA Chip access) or any other peripheral block with the 

exception of operating system permitted GPIO pins and timers. 
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2.1 .1 QA Manufacturer/owner code and OEM program code co-existing safely 

SoPEC includes a CPU that must run both manufacturer/owner program code and OEM program 
code. The execution model envisaged for SoPEC is one where Manufacturer/owner program code 
forms an operating system (O/S), providing services such as controlling the print engine pipeline, 
5 interfaces to communications channels etc. The OEM program code must run in a form of user 
mode, protected from harming the Manufacturer/owner program code. The OEM program code is 
permitted to obtain services by calling functions in the O/S, and the O/S may also call OEM code at 
specific times. For example, the OEM program code may request that the O/S call an OEM interrupt 
service routine when a particular GPIO pin is activated. 

10 

In addition, we may wish to permit the OEM code to directly call functions in Manufacturer/owner 
code with the same permissions as the OEM code. For example, the Manufacturer/owner code may 
provide SHA1 as a service, and the OEM could call the SHA1 function, but execute that function 
with OEM permissions and not Silverbook permissions. 

15 

A basic requirement then, for SoPEC, is a form of protection management, whereby 
Manufacturer/owner and OEM program code can co-exist without the OEM program code 
damaging operations or services provided by the Manufacturer/owner O/S. Since services rely on 
SoPEC peripherals (such as USB2 Host, LSS Master, Timers etc) access to these peripherals 
20 should also be restricted to Manufacturer/owner program code only. 

2.1 .2 Manufacturer/owner operating parameters authentication 

A particular OEM will be licensed to run a Print Engine with a particular set of operating parameters 
(such as print speed or quality). The OEM and/or end-user can upgrade the operating license for a 
25 fee and thereby obtain an upgraded set of operating parameters. 

Neither the OEM nor end-user should be able to upgrade the operating parameters without paying 
the appropriate fee to upgrade the license. Similarly, neither the OEM nor end-user should be able 
to bypass the authentication mechanism via any program code on SoPEC. This implies that OEMs 
30 and end-users must not be able to tamper with or replace Manufacturer/owner program code or 
data, nor be able to call unauthorized functions within Manufacturer/owner program code. 

However, the OEM must be capable of assembly-line testing the Print Engine at the upgraded 
status before selling the Print Engine to the end-user. 

35 
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2.1 .3 OEM operating parameters authentication 

The OEM may provide operating parameters to the end-user independent of the 

Manufacturer/owner operating parameters. For example, the OEM may want to sell a franking 

machine 1 . 

5 

The end-user should not be able to upgrade the operating parameters without paying the 
appropriate fee to the OEM. Similarly, the end-user should not be able to bypass the authentication 
mechanism via any program code on SoPEC. This implies that end-users must not be able to 
tamper with or replace OEM program code or data, as well as not be able to tamper with the PEP 
1 0 blocks or service-related peripherals. 

2.2 Acceptable Compromises 

If an end user takes the time and energy to hack the print engine and thereby succeeds in 
upgrading the single print engine only, yet not be able to use the same keys etc on another print 
1 5 engine, that is an acceptable security compromise. However it doesn't mean we have to make it 
totally simple or cheap for the end-user to accomplish this. 

Software-only attacks are the most dangerous, since they can be transmitted via the internet and 
have no perceived cost. Physical modification attacks are far less problematic, since most printer 
20 users are not likely to want their print engine to be physically modified. This is even more true if the 
cost of the physical modification is likely to exceed the price of a legitimate upgrade. 

2.3 Implementation Constraints 

Any solution to the requirements detailed in Section 2.1 should also meet certain preferred 
25 implementation constraints. These are: 
o No flash memory inside SoPEC 
o SoPEC must be simple to verify 

o Manufacturer/owner program code must be updateable 
o OEM program code must be updateable 
30 o Must be bootable from activity on USB2 

o Must be bootable from an external ROM to allow stand-alone printer operation 
o No extra pins for assigning IDs to slave SoPECs 

o Cannot trust the comms channel to the OA Chip in the printer (PRINTER_QA) 
o Cannot trust the comms channel to the QA Chip in the ink cartridges (INK_QA) 



1 a franking machine prints stamps 
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o Cannot trust the USB comms channel 
These constraints are detailed below. 



2.3.1 No flash memory inside SoPEC 

5 The preferred embodiment of SoPEC is intended to be implemented in 0.13 micron or smaller. 
Flash memory will not be available in any of the target processes being considered. 

2.3.2 SoPEC must be simple to verify 

All combinatorial logic and embedded program code within SoPEC must be verified before 
1 0 manufacture. Every increase in complexity in either of these increases verification effort and 
increases risk. 

2.3.3 Manufacturer/owner program code must be updateable 

It is neither possible nor desirable to write a single complete operating system that is: 
15 o verified completely (see Section 2.3.1 ) 

o correct for all possible future uses of SoPEC systems 
o finished in time for SoPEC manufacture 

Therefore the complete Manufacturer/owner program code must not permanently reside on SoPEC. 
It must be possible to update the Manufacturer/owner program code as enhancements to 
20 functionality are made and bug fixes are applied. 

In the worst case, only new printers would receive the new functionality or bug fixes. In the best 
case, existing SoPEC users can download new embedded code to enable functionality or bug fixes. 
Ideally, these same users would be obtaining these updates from the OEM website or equivalent, 
25 and not require any interaction with Manufacturer/owner. 

2.3.4 OEM program code must be updateable 

Given that each OEM will be writing specific program code for printers that have not yet been 
conceived, it is impossible for all OEM program code to be embedded in SoPEC at the ASIC 
30 manufacture stage. 

Since flash memory is not available (see Section 2.3.1), OEMs cannot store their program code in 
on-chip flash. While it is theoretically possible to store OEM program code in ROM on SoPEC, this 
would entail OEM-specific ASICs which would be prohibitively expensive. Therefore OEM program 
35 code cannot permanently reside on SoPEC. 
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Since OEM program code must be downloadable for SoPEC to execute, it should therefore be 
possible to update the OEM program code as enhancements to functionality are made and bug 
fixes are applied. 



5 In the worst case, only new printers would receive the new functionality or bug fixes. In the best 

case, existing SoPEC users can download new embedded code to enable functionality or bug fixes. 
Ideally, these same users would be obtaining these updates from the OEM website or equivalent, 
and not require any interaction with Manufacturer/owner. 

1 0 2.3.5 Must be bootable from activity on USB2 

SoPEC can be placed in sleep mode to save power when printing is not required. RAM is not 
preserved in sleep mode. Therefore any program code and data in RAM will be lost. However, 
SoPEC must be capable of being woken up by the host when it is time to print again. 
In the case of a single SoPEC system, the host communicates with SoPEC via USB2. From 

1 5 SoPEC's point of view, it is activity on the USB2 device port that signals the time to wake up. 

In the case of a multi-SoPEC system, the host typically communicates with the Master SoPEC chip 
(as above), and then the Master relays messages to other Slave SoPECs by sending data out 
USB2 host port(s) and into the Slave SoPEC's device port. The net result is that the Slave SoPECs 
and the Master SoPEC all boot as a result of activity on the USB2 device port. 

20 Therefore SoPEC must be capable of being woken up by activity on the USB2 device port. 

2.3.6 Must be bootable from an external ROM to allow stand-alone printer operation 
SoPEC must also support the case where the printer is not connected to a PC (or the PC is 
currently turned off), and a digital camera or equivalent is plugged into the SoPEC-based printer. In 
25 this case, the entire printing application needs to be present within the hardware of the printer. 

Since the Manufacturer/owner program code and OEM program code will vary depending on the 
application (see Section 2.3.3 and Section 2.3.4), it is not possible to store the program in SoPEC's 
ROM. 

30 Therefore SoPEC requires a means of booting from a non-PC host. It is possible that this could be 
accomplished by the OEM adding a USB2-host chip to the printer and simulating the effect of a PC, 
and thereby download the program code. This solution requires the boot operation to be based on 
USB2 activity (see Section 2.3.5). However this is an unattractive solution since it adds 
microprocessor complexity and component cost when only a ROM-equivalent was desired. 

35 As a result SoPEC should ideally be able to boot from an external ROM of some kind. Note that 
booting from an external ROM means first booting from the internal ROM, and then downloading 
and authenticating the startup section of the program from the external ROM. This is not the same 
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as simply running program code in-situ within an external ROM, since one of the security 
requirements was that OEMs and end-users must not be able to replace or tamper with 
Manufacturer/owner program code or data, i.e. we never want to blindly run code from an external 
ROM. 

5 

As an additional point, if SoPEC is in sleep mode, SoPEC must be capable of instigating the boot 
process due to activity on a programmable GPIO. e.g. a wake-up button. This would be in addition 
to the standard power-on booting. 

1 0 2.3.7 No extra pins to assign IDs to slave SoPECs 

In a single SoPEC system the host only sends data to the single SoPEC. However in a multi- 
SoPEC system, each of the slaves needs to be uniquely identifiable in order to be able for the host 
to send data to the correct slave. 

1 5 Since there is no flash on board SoPEC (Section 2.3.1 ) we are unable to store a slave ID in each 
SoPEC. Moreover, any ROM in each SoPEC will be identical. 

It is possible to assign n pins to allow 2 n combinations of IDs for slave SoPECs. However a design 
goal of SoPEC is to minimize pins for cost reasons, and this is particularly true of features only used 
20 in multi-SoPEC systems. 

The design constraint requirement is therefore to allow slaves to be IDed via a method that does not 
require any extra pins. This implies that whatever boot mechanism that satisfies the security 
requirements of Section 2.1 must also be able to assign IDs to slave SoPECs. 

25 

2.3.8 Cannot trust the comms channel to the QA Chip in the printer (PRINTER_QA) 

If the printer operating parameters are stored in the non-volatile memory of the Print Engine's on- 
board PRINTER_QA chip, both Manufacturer/owner and OEM program code cannot rely on the 
communication channel being secure. It is possible for an attacker to eavesdrop on communications 
30 to the PRINTERJ3A chip, replace the PRINTER_QA chip and/or subvert the communications 

channel. It is also possible for this to be true during manufacture of the circuit board containing the 
SoPEC and the PRINTER_QA chip. 

2.3.9 Cannot trust the comms channel to the QA Chip in the ink cartridges (INK_QA) 

35 The amount of ink remaining for a given ink cartridge is stored in the non-volatile memory of that ink 
cartridge's INK_QA chip. Both Manufacturer/owner and OEM program code cannot rely on the 
communication channel to the INK_QA being secure. It is possible for an attacker to eavesdrop on 
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communications to the INK_QA chip, to replace the INK_QA chip and/or to subvert the 
communications channel. It is also possible for this to be true during manufacture of the 
consumable containing the INK_QA chip. 

5 2.3.10 Cannot trust the inter-SoPEC comms channel (USB2) 

In a multi-SoPEC system, or in a single-SoPEC system that has a non-USB2 connection to the 
host, a given SoPEC will receive its data over a USB2 host port. It is quite possible for an end-user 
to insert a chip that eavesdrops on and/or subverts the communications channel (for example 
performs man-in-the-middle attacks). 

10 

3 Proposed Solution 

A proposed solution to the requirements of Section 2, can be summarised as: 
© Each SoPEC has a unique id 
o CPU with user/supervisor mode 
15 o Memory Management Unit 
o The unique id is not cached 
o Specific entry points in O/S 

o Boot procedure, including authentication of program code and operating parameters 
o SoPEC physical identification 

20 

3.1 Each SoPEC has a unique id 

Each SoPEC needs to contains a unique SoPECJd of minimum size 64-bits. This SoPECJd is 
used to form a symmetric key unique to each SoPEC: SoPECJd_key. On SoPEC we make use of 
an additional 1 1 2-bit ECID 2 macro that has been programmed with a random number on a per-chip basis. 
25 Thus SoPECJd is the 1 12-bit macro, and the SoPECJd key is a 160-bit result obtained by 
SHAl(SoPECJd). 

The verification of operating parameters and ink usage depends on SoPECJd being difficult to 
determine. Difficult to determine means that someone should not be able to determine the id via 
30 software, or by viewing the communications between chips on the board. If the SoPECJd is 

available through running a test procedure on specific test pins on the chip, then depending on the 
ease by which this can be done, it is likely to be acceptable. 
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It is important to note that in the proposed solution, compromise of the SoPECJd leads only to 
compromise of the operating parameters and ink usage on this particular SoPEC. It does not 
compromise any other SoPEC or all inks or operating parameters in general. 

5 It is ideal that the SoPECJd be random, although this is unlikely to occur on standard manufacture 
processes for ASICs. If the id is within a small range however, it will be able to be broken by brute 
force. This is why 32-bits is not sufficient protection. 

3.2 CPU WITH USER/SUPERVISOR MODE 

1 0 SoPEC contains a CPU with direct hardware support for user and supervisor modes. At present, the 
intended CPU is the LEON (a 32-bit processor with an instruction set according to the IEEE-1754 
standard. The IEEE1754 standard is compatible with the SPARC V8 instruction set). 

Manufacturer/owner (operating system) program code will run in supervisor mode, and all OEM 
1 5 program code will run in user mode. 

3.3 Memory Management Unit 

SoPEC contains a Memory Management Unit (MMU) that limits access to regions of DRAM by 
defining read, write and execute access permissions for supervisor and user mode. Program code 
20 running in user mode is subject to user mode permission settings, and program code running in 
supervisor mode is subject to supervisor mode settings. 

A setting of 1 for a permission bit means that type of access (e.g. read, write, execute) Is permitted. 
A setting of 0 for a read permission bit means that that type of access is not permitted. 

25 

At reset and whenever SoPEC wakes up, the settings for all the permission bits are 1 for all 
supervisor mode accesses, and 0 for all user mode accesses. This means that supervisor mode 
program code must explicitly set user mode access to be permitted on a section of DRAM. 

30 Access permission to all the non-valid address space should be trapped, regardless of user or 
supervisor mode, and regardless of the access being read, execute, or write. 

Access permission to all of the valid non-DRAM address space (for example the PEP blocks) is 
supervisor read / write access only (no supervisor execute access, and user mode has no acccess 
35 at all) with the exception that certain GPIO and Timer registers can also be accessed by user code. 
These registers will require bitwise access permissions. Each peripheral block will determine how 
the access is restricted. 
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With respect to the DRAM and PEP subsystems of SoPEC, typically we would set user 
read/write/execute mode permissions to be 1/1/0 only in the region of memory that is used for OEM 
program data, 1/0/1 for regions of OEM program code, and 0/0/0 elsewhere (including the trap 
table). By contrast we would typically set supervisor mode read/write/execute permissions for this 
5 memory to be 1/1/0 (to avoid accidentally executing user code in supervisor mode). 

The SoPECJd parameter (see Section 3.1) should only be accessible in supervisor mode, and 
should only be stored and manipulated in a region of memory that has no user mode access. 

1 0 3.4 Unique Id is not Cached 

The unique SoPECJd needs to be available to supervisor code and not available to user code. This 
is taken care of by the MMU (Section 3.3). 

However the SoPECJd must also not be accessable via the CPU's data cache or register windows. 
1 5 For example, if the user were to cause an interrupt to occur at a particular point in the program 

execution when the SoPECJd was being manipulated, it must not be possible for the user program 
code to turn caching off and then access the SoPECJd inside the data cache. This would bypass 
any MMU security. 

20 The same must be true of register windows. It must not be possible for user mode program code to 
read or modify register settings in a supervisor program's register windows. 

This means that at the least, the SoPECJd itself must not be cacheable. Likewise, any processed 
form of the SoPECJd such as the SoPECJd_key (e.g. read into registers or calculated expected 
25 results from a QA_Chip) should not be accessable by user program code. 

3.5 Specific entry points in O/S 

Given that user mode program code cannot even call functions in supervisor code space, the 
question arises as how OEM programs can access functions, or request services. The 
30 implementation for this depends on the CPU. 

On the LEON processor, the TRAP instruction allows programs to switch between user and 
supervisor mode in a controlled way. The TRAP switches between user and supervisor register 
sets, and calls a specific entry point in the supervisor code space in supervisor mode. The TRAP 
35 handler dispatches the service request, and then returns to the caller in user mode. 
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Use of a command dispatcher allows the O/S to provide services that filter access - e.g. a 
generalised print function will set PEP registers appropriately and ensure QA Chip ink updates 
occur. 

5 The LEON also allows supervisor mode code to call user mode code in user mode. There are a 
number of ways that this functionality can be implemented. It is possible to call the user code 
without a trap, but to return to supervisor mode requires a trap (and associated latency). 

3.6 Boot Procedure 

10 3.6.1 Basic premise 

The intention is to load the Manufacturer/owner and OEM program code into SoPEC's RAM, where 
it can be subsequently executed. The basic SoPEC therefore, must be capable of downloading 
program code. However SoPEC must be able to guarantee that only authorized 
Manufacturer/owner boot programs can be loaded, otherwise anyone could modify the O/S to do 

1 5 anything, and then load that - thereby bypassing the licensed operating parameters. 

We perform authentication of program code and data using asymmetric (public-key) digital 
signatures and without using a QA Chip. 

20 Assuming we have already downloaded some data and a 160-bit signature into eDRAM, the boot 
loader needs to perform the following tasks: 

© perform SHA-1 on the downloaded data to calculate a digest focalDigest 
° perform asymmetric decryption on the downloaded signature (160-bits) using an asymmetric 
public key to obtain authorizedDigest 
25 o if authorizedDigest is the PKCS#1 (patent free) form of locaiDigest, then the downloaded 
data is authorized (the signature must have been signed with the asymmetric private key) 
and control can then be passed to the downloaded data 
Asymmetric decryption is used instead of symmetric decryption because the decrypting key must be 
held in SoPEC's ROM. If symmetric private keys are used, the ROM can be probed and the security 
30 is compromised. 

The procedure requires the following data item: 
o bootOkey = an n-bit asymmetric public key 

35 The procedure also requires the following two functions: 

o SHA-1= a function that performs SHA-1 on a range of memory and returns a 160-bit digest 
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o decrypt = a function that performs asymmetric decryption of a message using the passed-in 
key 

o PKCS#1 form of localDigest is 2048-bits formatted as 
5 follows: bits 2047-2040 = 0x00, bits 2039-2032 = 0x01, 

bits 2031-288 = OxFF.. OxFF, bits 287-160 

Ox003021300906052BOE03021A05000414, bits 159-0 

localDigest. For more information, see PKCS#1 v2 . 1 section 
9.2 

10 

Assuming that all of these are available (e.g. in the boot ROM), boot loader 0 can be defined as in 
the following pseudocode: 

bootloaderO (data, sig) 

localDigest <- SHA-l(data) 
15 author izedDigest <— decrypt (sig, bootOkey) 

expectedDigest = 0x00 | 0x01 | OxFF . . OxFF | 

OX003021300906052BOE03021A05000414 | localDigest) // 

"|" = concat 

If (authorizedDigest == expectedDigest) 
20 jump to program code at data-start address// will never 

return 

Else 

// program code is unauthorized 
Endlf 

25 The length of the key will depend on the asymmetric algorithm chosen. The key must provide the 
equivalent protection of the entire OA Chip system - if the Manufacturer/owner O/S program code 
can be bypassed, then it is equivalent to the QA Chip keys being compromised. In fact it is worse 
because it would compromise Manufacturer/owner operating parameters, OEM operating 
parameters, and ink authentication by software downloaded off the net (e.g. from some hacker). 

30 

In the case of RSA, a 2048-bit key is required to match the 160-bit symmetric-key security of the QA 
Chip. In the case of ECDSA, a key length of 132 bits is likely to suffice. RSA is convenient because 
the patent (US patent number 4,405,829) expired in September 2000. 

35 There is no advantage to storing multiple keys in SoPEC and having the external message choose 
which key to validate against, because a compromise of any key allows the external user to always 
select that key. 
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There is also no particular advantage to having the boot mechanism select the key (e.g. one for 
USB-based booting and one for external ROM booting) a compromise of the external ROM booting 
key is enough to compromise all the SoPEC systems. 

5 However, there are advantages in having multiple keys present in the boot ROM and having a wire- 
bonding option on the pads select which of the keys is to be used. Ideally, the pads would be 
connected within the package, and the selection is not available via external means once the die 
has ben packaged. This means we can have different keys for different application areas (e.g. 
different uses of the chip), and if any particular SoPEC key is compromised, the die could be kept 
1 0 constant and only the bonding changed. Note that in the worst case of all keys being compromised, 
it may be economically feasible to change the bootOkey value in SoPEC's ROM, since this is only a 
single mask change, and would be easy to verify and characterize. 

Therefore the entire security of SoPEC is based on keeping the asymmetric private key paired to 
1 5 bootOkey secure. The entire security of SoPEC is also based on keeping the program that signs 
(i.e. authorizes) datasets using the asymmetric private key paired to bootOkey secure. 
It may therefore be reasonable to have multiple signatures (and hence multiple signature programs) 
to reduce the chance of a single point of weakness by a rogue employee. Note that the 
authentication time increases linearly with the number of signatures, and requires a 2048-bit public 
20 key in ROM for each signature. 

3.6.2 Hierarchies of authentication 

Given that test programs, evaluation programs, and Manufacturer/owner O/S code needs to be 
written and tested, and OEM program code etc. also needs to be tested, it is not secure to have a 
25 single authentication of a monolithic dataset combining Manufacturer/owner O/S, non-O/S, and 

OEM program code - we certainly don't want OEMs signing Manufacturer/owner program code, and 
Manufacturer/owner shouldn't have to be involved with the signing of OEM program code. 

Therefore we require differing levels of authentication and therefore a number of keys, although the 
30 procedure for authentication is identical to the first - a section of program code contains the key and 
procedure for authenticating the next. 

This method allows for any hierarchy of authentication, based on a root key of bootOkey. For 
example, assume that we have the following entities: 
35 o QACo, Manufacturer/owner's OA/key company. Knows private version of bootOkey, and 
owner of security concerns. 
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o SoPECCo, Manufacturer/owner's SoPEC hardware / software company. Supplies SoPEC 

ASICs and SoPEC O/S printing software to a ComCo. 
o ComCo, a company that assembles Print Engines from SoPECs, Memjet printheads etc, 

customizing the Print Engine for a given OEM according to a license 
5 o OEM, a company that uses a Print Engine to create a printer product to sell to the end-users. 

The OEM would supply the motor control logic, user interface, and casing. 



The levels of authentication hierarchy are as follows: 

© QACo writes the boot ROM, agenerates datasetl, consisting of a boot loader program that 

1 0 loads and validates dataset2 and QACo's asymmetric public bootlkey. QACo signs datasetO 

with the asymmetric private bootOkey. 
o SoPECCo generates datasetl, consisting of the print engine security kernel O/S (which 

incorporates the security-based features of the print engine functionality) and the ComCo's 
asymmetric public key. Upon a special "formal release" request from SoPECCo, QACo signs 

1 5 datasetO with QACo's asymmetric private bootOkey key. The print engine program code 

expects to see an operating parameter block signed by the ComCo's asymmetric private key. 
Note that this is a special "formal release" request to by SoPECCo; the procedure for 
development versions of the program are described in Section 3.6.3. 
o The ComCo generates dataSet3, consisting of datasetl plus dataset2 t where dataset2 is an 

20 operating parameter block for a given OEM's print engine licence (according to the print 

engine license arrangement) signed with the ComCo's asymmetric private key. The operating 
parameter block (dataset2) would contain valid print speed ranges, a PrintEngineLicenseld, 
and the OEM's asymmetric public key. The ComCo can generate as many of these operating 
parameter blocks for any number of Print Engine Licenses, but cannot write or sign any 

25 supervisor O/S program code. 

o The OEM would generate dataset5, consisting of dataset3 plus dataset4 t where dataset4 is 
the OEM program code signed with the OEM's asymmetric private key. The OEM can 
produce as many versions of datasetd as it likes (e.g. for testing purposes or for updates to 
drivers etc) and need not involve Manufacturer/owner, QACo, or ComCo in any way. 

30 The relationship is shown below in Figure 325. 

When the end-user uses datasetS, SoPEC itself validates datasetl via the bootOkey mechanism 
described in Section 3.6.1 . Once datasetl is executing, it validates dataset2 t and uses dataset2 
data to validate dataset4. The validation hierarchy is shown in Figure 326. 



35 



If a key is compromised, it compromises all subsequent authorizations down the hierarchy. In the 
example from above (and as illustrated in Figure 326) if the OEM's asymmetric private key is 
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compromised, then O/S program code is not compromised since it is above OEM program code in 
the authentication hierarchy. However if the ComCo's asymmetric private key is compromised, then 
the OEM program code is also compromised. A compromise of bootOkey compromises everything 
up to SoPEC itself, and would require a mask ROM change in SoPEC to fix. 

5 

It is worthwhile repeating that in any hierarchy the security of the entire hierarchy is based on 
keeping the asymmetric private key paired to bootOkey secure. It is also a requirement that the 
program that signs (i.e. authorizes) datasets using the asymmetric private key paired to bootOkey 
secure. 

10 

3.6.3 Developing Program Code at Manufacturer/owner 

The hierarchical boot procedure described in Section 3.6.1 and Section 3.6.2 gives a hierarchy of 
protection in a final shipped product. 

15 It is also desirable to use a hierarchy of protection during software development within 
Manufacturer/owner. 

For a program to be downloaded and run on SoPEC during development, it will need to be signed. 
In addition, we don't want to have to sign each and every Manufacturer/owner development code 
20 with the bootOkey, as it creates the possibility of any developmental (including buggy or rogue) 
application being run on any SoPEC. 

Therefore QACo needs to generate/create a special intermediate boot loader, signed with bootOkey, 
that performs the exact same tasks as the normal boot loader, except that it checks the SoPECid to 

25 see if it is a specific SoPECid (or set of SoPECids). If the SoPECJd is in the valid set, then the 
developmental boot loader validates dataset2 by means of its length and a SHA-1 digest of the 
developmental code 3 , and not by a further digital signature. The QACo can give this boot loader to 
the software development team within Manufacturer/owner. The software team can now write and 
run any program code, and load the program code using the development boot loader. There is no 

30 requirement for the subsequent software program (i.e. the developmental program code) to be 
signed with any key since the programs can only be run on the particular SoPECs. 



^he SHA-1 digest is to allow the total program load time to simulate the running time of the normal boot loader 
running on a non-developmental version of the program. 
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If the developmental boot loader (and/or signature generator) were compromised, or any of the 
developmental programs were compromised, the worst situation is that an attacker could run 
programs on that particular set of SoPECs, and on no others. 

5 This should greatly reduce the possibility of erroneous programs signed with bootOkey being 

available to an attacker (only official releases are signed by bootOkey), and therefore reduces the 
possibility of a Manufacturer/owner employee intentionally or inadvertently creating a back door for 
attackers. 

1 0 The relationship is shown below in Figure 327. 

Theoretically the same kind of hierarchy could also be used to allow OEMs to be assured that their 
program code will only work on specific SoPECs, but this is unlikely to be necessary, and is 
probably undesirable. 

15 

3.6.4 Date-limited loaders 

It is possible that errors in supervisor program code (e.g. the operating system) could allow 
attackers to subvert the program in SoPEC and gain supervisor control. 

20 To reduce the impact of this kind of attack, it is possible to allocate some bits of the SoPECJd to 
form some kind of date. The granularity of the date could be as simple as a single bit that says the 
date is obtained from the regular IBM ECID, or it could be 6 bits that give 10 years worth of 3-month 
units. 

25 The first step of the program loaded by boot loader 0 could check the SoPECJd date, and run or 
refuse to run appropriately. The Manufacturer/owner driver or OS could therefore be limited to run 
on SoPECs that are manufactured up until a particular date. 

This means that the OEM would require a new version of the OS for SoPECs after a particular date, 
30 but the new driver could be made to work on all previous versions of SoPEC. 

The function simply requires a form of date, whose granularity for working can be determined by 
agreement with the OEM. 

35 For example, suppose that SoPECs are supplied with 3-month granularity in their date components. 
Manufacturer/owner could ship a version of the OS that works for any SoPEC of the date (i.e. on 
any chip), or for all SoPECs manufactured during the year etc. The driver issued the next year could 
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work with all SoPECs up until that years etc. In this way the drivers for a chip will be backwards 
compatible, but will be deliberately not forwards-compatible. It allows the downloading of a new 
driver with no problems, but it protects against bugs in one years's driver OS from being used 
against future SoPECs. 

5 

Note that the phasing in of a new OS doesn't have to be at the same time as the hardware. For 
example, the new OS can come in 3 months before the hardware that it supports. However once 
the new SoPECs are being delivered, the OEM must not ship the older driver with the newer 
SoPECs, for the old driver will not work on the newer SoPECs. Basically once the OEM has 
1 0 received the new driver, they should use that driver for all SoPEC systems from that point on (old 
SoPECs will work with the new driver). 

This date-limiting feature would most likely be using a field in the ComCo specified operating 
parameters, so it allows the SoPEC to use date-checking in addition to additional OA Chip related 
1 5 parameter checking (such as the OEM's PrintEngineLicenseld etc). 

A variant on this theme is a date-window, where a start-date and end-date are specified (as relating 
to SoPEC manufacture, not date of use). 

20 3.6.5 Authenticating operating parameters 

Operating parameters need to be considered in terms of Manufacturer/owner operating parameters 
and OEM operating parameters. Both sets of operating parameters are stored on the PRINTER_QA 
chip (physically located inside the printer). This allows the printer to maintain parameters regardless 
of being moved to different computers, or a loss/replacement of host O/S drivers etc. 

25 

On PRINTER_QA, memory vector M 0 contains the upgradable operating parameters, and memory 
vectors M 1+ contains any constant (non-upgradable) operating parameters. 

Considering only Manufacturer/owner operating parameters for the moment, there are actually two 
30 problems: 

a. setting and storing the Manufacturer/owner operating parameters, which should be authorized 
only by Manufacturer/owner 

b. reading the parameters into SoPEC, which is an issue of SoPEC authenticating the data on the 
PRINTERJ3A chip since we don't trust PRINTER_QA. 

35 The PRINTER_QA chip therefore contains the following symmetric keys: 
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o Ko = PrintEngineLicense_key. This key is constant for ail SoPECs supplied for a given print 
engine license agreement between an OEM and a Manufacturer/owner ComCo. Ko has write 
permissions to the Manufacturer/owner upgradeable region of M 0 on PRINTER_QA. 

o = SoPECJdJkey. This key is unique for each SoPEC (see Section 3.1 ), and is known only 

5 to the SoPEC and PRINTER_QA. does not have write permissions for anything. 

Ko is used to solve problem (a). It is only used to authenticate the actual upgrades of the operating 
parameters. Upgrades are performed using the standard upgrade protocol described in [5], with 
PRINTER_QA acting as the ChipU, and the external upgrader acting as the ChipS. 

10 

Ki is used by SoPEC to solve problem (b). It is used to authenticate reads of data (i.e. the operating 
parameters) from PRINTER_QA. The procedure follows the standard authenticated read protocol 
described in [5], with PRINTER_QA acting as ChipR, and the embedded supervisor software on 
SoPEC acting as ChipT. The authenticated read protocol [5] requires the use of a 160-bit nonce, 
1 5 which is a pseudo-random number. This creates the problem of introducing pseudo-randomness 
into SoPEC that is not readily determinable by OEM programs, especially given that SoPEC boots 
into a known state. One possibility is to use the same random number generator as in the QA Chip 
(a 160-bit maximal-lengthed linear feedback shift register) with the seed taken from the value in the 
WatchDogTimer register in SoPECs timer unit when the first page arrives. 

20 

Note that the procedure for verifying reads of data from PRINTER_QA does not rely on 
Manufacturer/owner's key Ko. This means that precisely the same mechanism can be used to read 
and authenticate the OEM data also stored in PRINTER_QA. Of course this must be done by 
Manufacturer/owner supervisor code so that SoPECJdJkey is not revealed. 

25 

If the OEM also requires upgradable parameters, we can add an extra key to PRINTER_QA, where 
that key is an OEM_key and has write permissions to the OEM part of M 0 . 

In this way, K A never needs to be known by anyone except the SoPEC and PRINTER_QA. 

30 

Each printing SoPEC in a multi-SoPEC system need access to a PRINTER_QA chip that contains 
the appropriate SoPEC Jdjkey to validate ink useage and operating parameters. This can be 
accomplished by a separate PRINTER_QA for each SoPEC, or by adding extra keys (multiple 
SoPECJd__keys) to a single PRINTER_QA. 

35 

However, if ink usage is not being validated (e.g. if print speed were the only Manufacturer/owner 
upgradable parameter) then not all SoPECs require access to a PRINTER_QA chip that contains 
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the appropriate SoPEC_id_key. Assuming that OEM program code controls the physical motor 
speed (different motors per OEM), then the PHI within the first (or only) front-page SoPEC can be 
programmed to accept (or generate) line sync pulses no faster than a particular rate. If line syncs 
arrived faster than the particular rate, the PHI would simply print at the slower rate. If the motor 
5 speed was hacked to be fast, the print image will appear stretched. 

3. 6. 5. 1 Floating operating parameters and dongies 

As described in Section 2.1.2, Manufacturer/owner operating parameters include such items as 
print speed, print quality etc. and are tied to a license provided to an OEM. These parameters are 
1 0 under Manufacturer/owner control. The licensed Manufacturer/owner operating parameters are typ- 
ically stored in the PRINTER_QA as described in Section 3.6.5. 

However there are situations when it is desirable to have a floating upgrade to a license, for use on 
a printer of the user's choice. For example, OEMs may sell a speed-increase license upgrade that 
1 5 can be plugged into the printer of the user's choice. This form of upgrade can be considered a 
floating upgrade in that it upgrades whichever printer it is currently plugged into. This dongle is 
referred to as ADDITIONAL_PRINTER_QA. The software checks for the existence of an 
ADDITIONAL_PRINTER_QA, and if present the operating parameters are chosen from the values 
stored on both QA chips. 

20 

The basic problem of authenticating the additional operating parameters boils down to the problem 
that we don't trust ADDITIONAL_PRINTER_QA. Therefore we need a system whereby a given 
SoPEC can perform an authenticated read of the data in ADDITIONAL_PRINTER_QA. 

25 We should not write the SoPECJd_key to a key in the ADDITION AL_PRINTER_QA because: 
o then it will be tied specifically to that SoPEC, and the primary intention of the 

ADDITIONAL_PRINTER_QA is that it be floatable; 
o the ink cartridge would then not work in another printer since the other printer would not know 
the old SoPECJd_key (knowledge of the old key is required in order to change the old key to 
30 a new one). 

o updating keys is not power-safe (i.e. if at the user's site, power is removed mid-update, the 
ADDITIONAL_PRINTER_QA could be rendered useless) 
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The proposed solution is to let ADDITIONAL_PRINTER_QA have two keys: 

o Ko = FloatingPrintEngineUcense_key. This key has the same function as the 

PrintEngineLicenseJkey in the PRINTER_QA 4 in that Ko has write permissions to the 
Manufacturer/owner upgradeable region of Mo on ADDITION AL_PRINTER_Q A. 
5 o = UseExtParmsLicenseJkey. This key is constant for all of the 

ADDITIONAL_PRINTER_QAs for a given license agreement between an OEM and a 
Manufacturer/owner ComCo (this is not the same key as PrintEngineLicenseJkey which is 
stored as Kq in PRINTER_QA). K t has no write permissions to anything. 

10 Kq is used to allow writes to the various fields containing operating parameters in the 

ADDITIONAL_PRINTER_QA. These writes/upgrades are performed using the standard upgrade 
protocol described in [5], with ADDITIONAL_PRINTER_QA acting as the ChipU, and the external 
upgrader acting as the ChipS. The upgrader (ChipS) also needs to check the appropriate licensing 
parameters such as OEMJd for validity. 

15 

K, is used to allow SoPEC to authenticate reads of the ink remaining and any other ink data. This is 
accomplished by having the same UseExtParmsLicense_key within PRINTER_QA (e.g. in K 2 ), also 
with no write permissions, i.e: 

o PRINTER_QA.K 2 = UseExtParmsLicenseJkey. This key is constant for all of the 
20 PRINTER_QAs for a given license agreement between an OEM and a Manufacturer/owner 

ComCo. K 2 has no write permissions to anything. 

This means there are two shared keys, with PRINTER_QA sharing both, and thereby acting as a 
bridge between INK_QA and SoPEC. 
25 o UseExtParmsLicenseJkey is shared between PRINTER_QA and 
ADDITIONAL_PRINTER_QA 
o SoPECJd_key is shared between SoPEC and PRINTER_QA 

All SoPEC has to do is do an authenticated read [6] from ADDITIONAL_PRINTER_QA, pass the 
30 data / signature to PRINTER_QA, let PRINTER_QA validate the data / signature, and get 

PRINTER_QA to produce a similar signature based on the shared SoPECJdJkey. It can do so 
using the Translate function [6], SoPEC can then compare PRINTER_QA's signature with its own 
calculated signature (i.e. implement a Test function [6] in software on SoPEC), and if the signatures 
match, the data from ADDITIONAL_PRINTER_QA must be valid, and can therefore be trusted. 



^his can be identical to PrintEngineLicense_key in the PRINTER_QA if it is desireable (unlikely) that 
upgraders can function on PRINTER_QAs as well as AD D IT I O N AL_P R I NTE R_QAs 
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Once the data from ADDITIONAL_PRINTER_QA is known to be trusted, the various operating 
parameters such as OEMJd can be checked for validity. 

The actual steps of read authentication as performed by SoPEC are: 
5 R printer <~ PRINTER_QA. random () 

Rdongle / Mdongle , SIQdongle *~ DONGLE_QA . read ( Kl , Rprinter) 
Rsopec *~ random ( ) 

Rprinter / S I G printer PR INTER_QA . t r ans 1 a t e ( K2 , Rdongle / Mdongle , S I Goongle t 

Kl , Rsopec ) 

10 SIGsopec <~ HMAC_SHA_1 (SoPEC_id_key, Mangle | Rprinter | Rsopec) 

If (SIGprinter = SIGsopec) 

// various parms inside Mdqngle (data read from 
ADD I T I ONAL_PR INTER_QA ) is valid 
Else 

15 // the data read from ADDITTONAL_PRINTER_QA is not valid and 

cannot be trusted 
Endlf 

3. 6. 5. 2 Dongles tied to a given SoPEC 
20 Section 3.6.5.1 describes floating dongles i.e. dongles that can be used on any SoPEC. Sometimes 
it is desirable to tie a dongle to a specific SoPEC. 

Tying a QA_CHIP to be used only on a specific SoPEC can be easily accomplished by writing the 
PRINTER__QA's chipld (unique serial number) into an appropriate M 0 field on the 
25 ADDITIONAL__PRINTER_QA. The system software can detect the match and function 
appropriately. If there is no match, the software can ignore the data read from the 
ADDITIONAL_PRINTER_QA. 

Although it is also possible to store the SoPECJdJkey in one of the keys within the dongle, this 
30 must be done in an environment where power will not be removed partway through the key update 
process (if power is removed during the key update there is a possibility that the dongle QA Chip 
may be rendered unusable, although this can be checked for after the power failure). 
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3. 6. 5. 3 OEM assembly -line test 

Although an OEM should only be able sell the licensed operating parameters for a given Print 
Engine, they must be able to assembly-line test 5 or service/test the Print Engine with a different set 
of operating parameters e.g. a maximally upgraded Print Engine. 
5 Several different mechanisms can be employed to allow OEMs to test the upgraded capabilities of 
the Print Engine. At present it is unclear exactly what kind of assembly-line tests would be 
performed. 

The simplest solution is to use an ADDITIONAL_PRINTER_QA (i..e. special dongle PRINTER_QA 
10 as described in Section 3.6.5.1 ). The ADDITIONAL_PRINTER_QA would contain the operating 
parameters that maximally upgrade the printer as long as the dongle is connected to the SoPEC. 
The exact connection may be directly electrical (e.g. via the standard QA Chip connections) or may 
be over the USB connection to the printer test host depending on the nature of the test. The exact 
preferred connection is yet to be determined. 

15 

In the testing environment, the ADDITIONAL_PRINTER_QA also requires a numberOflmpressions 
field inside M 0l which is writeable by Kq. Before the SoPEC prints a page at the higher speed, it 
decrements the numberOflmpressions counter, performs an authenticated read to ensure the count 
was decremented, and then prints the page. In this way, the total number of pages that can be 
20 printed at high speed is reduced in the event of someone stealing the ADDITIONAL_PRINTER_QA 
device. It also means that multiple test machines can make use of the same 
ADDITIONAL_PRINTER_QA. 

3.6.6 Use of a PrintEngineLicense id 
25 Manufacturer/owner O/S program code contains the OEM's asymmetric public key to ensure that 
the subsequent OEM program code is authentic - i.e. from the OEM. However given that SoPEC 
only contains a single root key, it is theoretically possible for different OEM's applications to be run 
identically physical Print Engines i.e. printer driver for OEMi run on an identically physical Print 
Engine from OEM 2 . 

30 

To guard against this, the Manufacturer/owner O/S program code contains a PrintEngineLicenseJd 
code (e.g. 16 bits) that matches the same named value stored as a fixed operating parameter in the 
PRINTER_QA (i.e. in M 1+ ). As with all other operating parameters, the value of 
PrintEngineLicenseJd is stored in PRINTER_QA (and any ADDITIONAL_PRINTER_QA devices) 



^his section is referring to assembly-line testing rather than development testing. An OEM can maximally 
upgrade a given Print Engine to allow developmental testing of their own OEM program code & mechanics. 
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at the same time as the other various PRINTER_QA customizations are being applied, before being 
shipped to the OEM site. 

In this way, the OEMs can be sure of differentiating themselves through software functionality. 

5 

3.6.7 Authentication of ink 

The Manufacturer/owner O/S must perform ink authentication [6] during prints. Ink usage authen- 
tication makes use of counters in SoPEC that keep an accurate record of the exact number of dots 
printed for each ink. 

10 

The ink amount remaining in a given cartridge is stored in that cartridge's INK_QA chip. Other data 
stored on the INK_QA chip includes ink color, viscosity, Memjet firing pulse profile information, as 
well as licensing parameters such as OEMJd, inkType, InkUsageLicenseJd, etc. This information 
is typically constant, and is therefore likely to be stored in M 1+ within INK_QA. 

15 

Just as the Print Engine operating parameters are validated by means of PRINTER_QA, a given 
Print Engine license may only be permitted to function with specifically licensed ink. Therefore the 
software on SoPEC could contain a valid set of ink types, colors, OEMJds, InkUsageLicenseJds 
etc. for subsequent matching against the data in the INK_QA. 

20 

SoPEC must be able to authenticate reads from the INK_QA, both in terms of ink parameters as 
well as ink remaining. 

To authenticate ink a number of steps must be taken: 
25 o restrict access to dot counts 

o authenticate ink usage and ink parameters via INKJ3A and PRINTER_QA 
o broadcast ink dot usage to all SoPECs in a multi-SoPEC system 

3. 6. 7. 1 restrict access to dot counts 
30 Since the dot counts are accessed via the PHI in the PEP section of SoPEC, access to these 

registers (and more generally all PEP registers) must be only available from supervisor mode, and 
not by OEM code (running in user mode). Otherwise it might be possible for OEM program code to 
clear dot counts before authentication has occurred. 

35 3.6. 7.2 authenticate ink usage and ink parameters via INK_QA and PRINTER_QA 

The basic problem of authentication of ink remaining and other ink data boils down to the problem 
that we don't trust INK_QA. Therefore how can a SoPEC know the initial value of ink (or the ink 
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parameters), and how can a SoPEC know that after a write to the INK_QA, the count has been 
correctly decremented. 

Taking the first issue, which is determining the initial ink count or the ink parameters, we need a 
5 system whereby a given SoPEC can perform an authenticated read of the data in INK_QA. 

We cannot write the SoPECJd_key to the INK_QA for two reasons: 

o updating keys is not power-safe (i.e. if power is removed mid-update, the INK_QA could be 
rendered useless) 

10 o the ink cartridge would then not work in another printer since the other printer would not know 
the old SoPEC_id_key (knowledge of the old key is required in order to change the old key to a new 
one). 

The proposed solution is to let INK_QA have two keys: 
15 o Ko = Supply lnkLicense_key. This key is constant for all ink cartridges for a given ink supply 
agreement between an OEM and a Manufacturer/owner ComCo (this is not the same key as 
PrintEngineLicense_key which is stored as Kq in PRINTER_QA). Kq has write permissions to 
the ink remaining regions of M 0 on INK_QA. 
o «! = UselnkLicense_key. This key is constant for all ink cartridges for a given ink usage 
20 agreement between an OEM and a Manufacturer/owner ComCo (this is not the same key as 

PrintEngineLicenseJkey which is stored as Kq in PRINTER_QA). has no write permissions 
to anything. 

Ko is used to authenticate the actual upgrades of the amount of ink remaining (e.g. to fill and refill 
the amount of ink). Upgrades are performed using the standard upgrade protocol described in [5], 
25 with INK_QA acting as the ChipU, and the external upgrader acting as the ChipS. The fill and refill 
upgrader (ChipS) also needs to check the appropriate ink licensing parameters such as OEMJd, 
InkType and InkUsageLicenseJd for validity. 

Ki is used to allow SoPEC to authenticate reads of the ink remaining and any other ink data. This is 
30 accomplished by having the same UselnkLicense_key within PRINTER_QA (e.g. in K 2 or K 3 ), also 
with no write permissions. 

This means there are two shared keys, with PRINTER_QA sharing both, and thereby acting as a 
bridge between INK_QA and SoPEC. 
35 o UselnkLicense_key is shared between INK_QA and PRINTER_QA 
o SoPECJd_key is shared between SoPEC and PRINTER_QA 
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All SoPEC has to do is do an authenticated read [6] from INK_QA, pass the data / signature to 
PRINTER_QA, let PRINTER_QA validate the data / signature and get PRINTER_QA to produce a 
similar signature based on the shared SoPEC_id_key (i.e. the Translate function [6]). SoPEC can 
then compare PRINTER_QA's signature with its own calculated signature (i.e. implement a Test 
5 function [6] in software on the SoPEC), and if the signatures match, the data from INK_QA must be 
valid, and can therefore be trusted. 

Once the data from INK_QA is known to be trusted, the amount of ink remaining can be checked, 
and the other ink licensing parameters such as OEMJd, InkType, InkUsageLicenseJd can be 
1 0 checked for validity. 

The actual steps of read authentication as performed by SoPEC are: 
Rprinter <— PRINTER_QA. random () 

Rink, SIG^ <~ INK_QA . read ( Kl , Rprinter) // read with keyl : 

1 5 UseInkLicense_key 
Rsopec <— random () 

Rprinter, SIGprinter <r- PRINTER_QA. translate (K2 , R^, M^, SIGink, Kl , 
Rsopec ) 

SIGsopec <- HMAC_SHA_l(SoPEC_id_key, | R PRIN ter | Rsopec) 

20 If (SIGprinter = SIGsopec) 

// Mnnc (data read from INK_QA) is valid 

// Mhjk could be ink parameters, such as InkUsageLicense_Id, or 
ink remaining 

If (Mojk. inkRemaining = expectedlnkRemaining) 
25 // all is ok 

Else 

// the ink value is not what we wrote, so don't print 
anything anymore 
Endlf 
30 Else 

// the data read from INK_QA is not valid and cannot be trusted 
Endlf 

Strictly speaking, we don't need a nonce (Rsopec) all the time because M A (containing the ink 
remaining) should be decrementing between authentications. However we do need one to retrieve 
35 the initial amount of ink and the other ink parameters (at power up). This is why taking a random 
number from the WatchDogTimer at the receipt of the first page is acceptable. 
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In summary, the SoPEC performs the non-authenticated write [6] of ink remaining to the INK_QA 
chip, and then performs an authenticated read of the data via the PRINTER_QA as per the 
pseudocode above. If the value is authenticated, and the INK_QA ink-remaining value matches the 
expected value, the count was correctly decremented and the printing can continue. 

5 

3.6. 7.3 broadcast ink dot usage to all SoPECs in a multi-SoPEC system 

In a multi-SoPEC system, each SoPEC attached to a printhead must broadcast its ink usage to all 

the SoPECs. In this way, each SoPEC will have its own version of the expected ink usage. 

10 In the case of a man-in-the-middle attack, at worst the count in a given SoPEC is only its own count 
(i.e. all broadcasts are turned into 0 ink usage by the man-in-the-middle). We would also require the 
broadcast amount to be treated as an unsigned integer to prevent negative amounts from being 
substituted. 

15 A single SoPEC performs the update of ink remaining to the INK_QA chip, and then all SoPECs 
perform an authenticated read of the data via the appropriate PRINTER_QA (the PRINTER_QA 
that contains their matching SoPECJd_key- remember that multiple SoPEC_id_keys can be stored 
in a single PRINTER_QA). If the value is authenticated, and the INK_QA value matches the 
expected value, the count was correctly decremented and the printing can continue. 

20 

If any of the broadcasts are not received, or have been tampered with, the updated ink counts will 
not match. The only case this does not cater for is if each SoPEC is tricked (via a USB2 inter- 
SoPEC-comms man-in-the-middle attack) into a total that is the same, yet not the true total. Apart 
from the fact that this is not viable for general pages, at worst this is the maximum amount of ink 
25 printed by a single SoPEC. We don't care about protecting against this case. 

Since a typical maximum is 4 printing SoPECs, it requires at most 4 authenticated reads. This 
should be completed within 0.5 seconds, well within the 1-2 seconds/page print time. 

30 3.6.8 Example hierarchy 

Adding an extra bootloader step to the example from Section 3.6.2, we can break up the contents of 
program space into logical sections, as shown in Table 227. Note that the ComCo does not provide 
any program code, merely operating parameters that is used by the O/S. 
Table 227. Sections of Program Space 

35 



section 


contents 


verifies 


0 


boot loader 0 


section 1 via bootOkey 
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(ROM) 


SHA-1 function 
asymmetric decrypt function 
bootOkey 




1 


boot loader 1 
SoPEC_OS_public_key 


section 2 via SoPEC_OS_public_key 


2 


Manufacturer/owner O/S program 
code 

function to generate 
SoPEC Jd_key from SoPECJd 
Basic Print Engine 
ComCo_publicJ<ey 


section 3 via ComCo_public_key 
section 4 via OEM_public_key (supplied 
in section 3) 

PRINTER_QA data, which includes the 
PrintEngineLicenseJd, 
Manufacturer/owner operating 
parameters, and OEM operating 
parameters (all authenticated via 
SoPEC_id_key) 


3 


ComCo license agreement operat- 
ing parameter ranges, including 
PrintEngineLicenseJd (gets 
loaded into supervisor mode sec- 
tion of memory) 

OEM_public_key (gets loaded into 
supervisor mode section of mem- 
ory) 

Any ComCo written user-mode 
program code (gets loaded into 
mode mode section of memory) 


Is used by section 2 to verify section 4 
and range of parameters as found in 
PRINTERJ3A 


4 


OEM specific program code 


OEM operating parameters via calls to 
Manufacturer/owner O/S code 



The verification procedures will be required each time the CPU is woken up, since the RAM is not 
preserved. 

3.6.9 What if the CPU is not fast enough? 

In the example of Section 3.6.8, every time the CPU is woken up to print a document it needs to 
perform: 

o SHA-1 on all program code and program data 

o 4 sets of asymmetric decryption to load the program code and data 
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o 1 HMAC-SHA1 generation per 512-bits of Manufacturer/owner and OEM printer and ink oper- 
ating parameters 

Although the SHA-1 and HMAC process will be fast enough on the embedded CPU (the program 
5 code will be executing from ROM), it may be that the asymmetric decryption will be slow. And this 
becomes more likely with each extra level of authentication. If this is the case (as is likely), 
hardware acceleration is required. 

A cheap form of hardware acceleration takes advantage of the fact that in most cases the same 
1 0 program is loaded each time, with the first time likely to be at power-up. The hardware acceleration 
is simply data storage for the authorized Digest which means that the boot procedure now is: 

slowCPU_bootloaderO (data, sig) 
localDigest <- SHA-1 (data) 

If (localDigest = previous lyStoredAuthorizedDigest ) 
15 jump to program code at data-start address// will never 

return 

Else 

author! zedDigest <— decrypt (sig, bootOkey) 

expectedDigest = 0x00 | 0x01 | OxFF. . OxFF | 

20 0x003021300906052B0E03021A05000414 | localDigest) 

If (authorizedDigest == expectedDigest) 
previouslyStoredAuthorizedDigest <— localDigest 

jump to program code at data- start address// will 

never return 
25 Else 

// program code is unauthorized 
Endlf 

This procedure means that a reboot of the same authorized program code will only require SHA-1 
processing. At power-up, or if new program code is loaded (e.g. an upgrade of a driver over the 
30 internet), then the full authorization via asymmetric decryption takes place. This is because the 
stored digest will not match at power-up and whenever a new program is loaded. 

The question is how much preserved space is required. 

35 Each digest requires 160 bits (20 bytes), and this is constant regardless of the asymmetric 

encryption scheme or the key length. While it is possible to reduce this number of bits, thereby 
sacrificing security, the cost is small enough to warrant keeping the full digest. 
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However each level of boot loader requires its own digest to be preserved. This gives a maximum of 
20 bytes per loader. Digests for operating parameters and ink levels may also be preserved in the 
same way, although these authentications should be fast enough not to require cached storage. 

5 Assuming SoPEC provides for 12 digests (to be generous), this is a total of 240 bytes. These 240 
bytes could easily be stored as 60 x 32-bit registers, or probably more conveniently as a small 
amount of RAM (eg 0.25 - 1 Kbyte). Providing something like 1 Kbyte of RAM has the advantage of 
allowing the CPU to store other useful data, although this is not a requirement. 

10 In general, it is useful for the boot ROM to know whether it is being started up due to power-on 

reset, GPIO activity, or activity on the USB2. In the former case, it can ignore the previously stored 
values (either 0 for registers or garbage for RAM). In the latter cases, it can use the previously 
stored values. Even without this, a startup value of 0 (or garbage) means the digest won't match 
and therefore the authentication will occur implictly. 

15 

3.7 SoPEC Phsyical identification 

There must be a mapping of logical to physical since specific SoPECs are responsible for printing 
on particular physical parts of the page, and/or have particular devices attached to specific pins. 

20 The identification process is mostly solved by general USB2 enumeration. 

Each slave SoPEC will need to verify the boot broadcast messages received over USB2, and only 
execute the code if the signatures are valid. Several levels of authorization may occur. However, at 
some stage, this common program code (broadcast to all of the slave SoPECs and signed by the 
25 appropriate asymmetric private key) can, among other things, set the slave SoPECs id relating to 
the physical location. If there is only 1 slave, the id is easy to determine, but if there is more than 1 
slave, the id must be determined in some fashion. For example, physical location/id determination 
may be: 

o given by the physical USB2 port on the master 
30 © related to the physical wiring up of the USB2 interconnects 

o based on GPIO wiring. On other systems, a particular physical arrangement of SoPECs may 
exist such that each slave SoPEC will have a different set of connections on GPIOs. For 
example, one SoPEC maybe in charge of motor control, while another may be driving the 
LEDs etc. The unused GPIO pins (not necessarily the same on each SoPEC) can be set as 
35 inputs and then tied to 0 or 1 . As long as the connection settings are mutually exclusive, 

program code can determine which is which, and the id appropriately set. 
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This scheme of slave SoPEC Identification does not introduce a security breach. If an attacker 
rewires the pinouts to confuse identification, at best it will simply cause strange printouts (e.g. 
swapping of printout data) to occur, while at worst the Print Engine will simply not function. 

5 3.8 Setting up OA Chip keys 

In use, each INK_QA chip needs the following keys: 
o Kq = SupplylnkLicense_key 
o K<| = UselnkLicense_key 

1 0 Each PRINTERJ2A chip tied to a specific SoPEC requires the following keys: 

o Ko = PrintEngineLicense_key 

o Kt = SoPEC_id_key 

o K 2 = UseExtParmsLicense_key 

o K 3 = UselnkLicense_key 
1 5 Note that there may be more than one depending on the number of PRINTERJ3A chips and 

SoPECs in a system. These keys need to be appropriately set up in the QA Chips before they will 

function correctly together. 

3.8.1 Original QA Chips as received by a ComCo 
20 When original QA Chips are shipped from QACo to a specific ComCo their keys are as follows: 



o 


Ko = 


QACo_ 


ComCo_ 


KeyO 


o 


K, = 


QACo_ 


ComCo_ 


Key1 


o 


K 2 = 


QACo_ 


ComCo_ 


Key2 


o 


K 3 = 


QACo_ 


ComCo_ 


Key3 



25 All 4 keys are only known to QACo. Note that these keys are different for each QA Chip. 
3.8.2 Steps at the ComCo 

The ComCo is responsible for making Print Engines out of Memjet printheads, QA Chips, PECs or 
SoPECs, PCBs etc. 

30 

In addition, the ComCo must customize the INK_QA chips and PRINTER_QA chip on-board the 
print engine before shipping to the OEM. 
There are two stages: 

o replacing the keys in QA Chips with specific keys for the application (i.e. INK_QA and 
35 PRINTERJ3A) 

o setting operating parameters as per the license with the OEM 
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3. 8. 2. 1 Replacing keys 

The ComCo is issued QID hardware [4] by QACo that allows programming of the various keys 
(except for in a given QA Chip to the final values, following the standard ChipF/ChipP replace 
key (indirect version) protocol [6]. The indirect version of the protocol allows each 
5 QACo__ComCo__Key to be different for each SoPEC. 

In the case of programming of PRINTER_QA's to be SoPEC_id_key, there is the additional step 
of transferring an asymmetrically encrypted SoPECJdJkey (by the public-key) along with the nonce 
(R P ) used in the replace key protocol to the device that is functioning as a ChipF. The ChipF must 
1 0 decrypt the SoPECJd__key so it can generate the standard replace key message for PRINTER_QA 
(functioning as a ChipP in the ChipF/ChipP protocol). The asymmetric key pair held in the ChipF 
equivalent should be unique to a ComCo (but still known only by QACo) to prevent damage in the 
case of a compromise. 

1 5 Note that the various keys installed in the QA Chips (both INK_QA and PRINTER_QA) are only 
known to the QACo. The OEM only uses QIDs and QACo supplied ChipFs. The replace key 
protocol [6] allows the programming to occur without compromising the old or new key. 

3. 8. 2. 2 Setting operating parameters 

20 There are two sets of operating parameters stored in PRINTER_QA and INK_QA: 
o fixed 
© upgradable 

The fixed operating parameters can be written to by means of a non-authenticated writes [6] to M 1+ 
via a QID [4], and permission bits set such that they are Readonly. 

25 

The upgradable operating parameters can only be written to after the QA Chips have been 
programmed with the correct keys as per Section 3.8.2.1 . Once they contain the correct keys they 
can be programmed with appropriate operating parameters by means of a QID and an appropriate 
ChipS (containing matching keys). 
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AUTHENTICATION PROTOCOLS 

1 Introduction 

The following describes authentication protocols for general authentication applications, but with 
specific reference to the OA Chip. 

5 

The intention is to show the broad form of possible protocols for use in different authentication 
situations, and can be used as a reference when subsequently defining an implementation 
specification for a particular application. As mentioned earlier, although the protocols are described 
in relation to a printing environment, many of them have wider application such as, but not limited 
1 0 to, those described at the end of this specification. 

2 Nomenclature 

The following symbolic nomenclature is used throughout this document: 
Table 228. Summary of symbolic nomenclature 

15 



Symbol 


Description 


F[X] 


Function F, taking a single parameter X 


F[X,Y] 


Function F, taking two parameters, X and Y 


X | Y 


X concatenated with Y i 


XaY 


Bitwise X AND Y 


Xv Y 


Bitwise X OR Y (inclusive-OR) j 


X© Y 


Bitwise X XOR Y (exclusive-OR) 


-oc 


Bitwise NOT X (complement) 


X<-Y 


X is assigned the value Y 


X^{Y, Z} 


The domain of assignment inputs to X is Y and Z 


X = Y 


X is equal to Y 


X* Y 


X is not equal to Y 


Ux 


Decrement X by 1 (floor 0) 


fix 


Increment X by 1 (modulo register length) 


Erase X 


Erase Flash memory register X \ 


SetBits[X, Y] 


Set the bits of the Flash memory register X based on Y 


Z <r- ShiftRight[X, Y] 


Shift register X right one bit position, taking input bit 
from Y and placing the output bit in Z 
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3 Pseudocode 

3.1 Asynchronous 
The following pseudocode: 

var = expression 

5 means the var signal or output is equal to the evaluation of the expression. 

3.2 Synchronous 
The following pseudocode: 

var <— expression 

means the var register is assigned the result of evaluating the expression during 
1 0 this cycle. 

3.3 Expression 

Expressions are defined using the nomenclature in Table 228 above. Therefore: 

var = (a = b) 
is interpreted as the var signal is 1 if a is equal to b, and 0 otherwise. 

15 

4. Intentionally blank 



5 Basic Protocols 
5.1 Protocol background 
20 This protocol set is a restricted form of a more general case of a multiple key single memory vector 
protocol. It is a restricted form in that the memory vector M has been optimized for Flash memory 
utilization: 

o M is broken into multiple memory vectors (semi-fixed and variable components) for the 

purposes of optimizing flash memory utilization. Typically M contains some parts that are 
25 fixed at some stage of the manufacturing process (eg a batch number, serial number etc.), 

and once set, are not ever updated. This information does not contain the amount of 

consumable remaining, and therefore is not read or written to with any great frequency, 
o We therefore define M 0 to be the M that contains the frequently updated sections, and the 

remaining Ms to be rarely written to. Authenticated writes only write to M 0 , and non- 
30 authenticated writes can be directed to a specific M n . This reduces the size of permissions 

that are stored in the QA Chip (since key-based writes are not required for Ms other than M 0 ). 

It also means that M 0 and the remaining Ms can be manipulated in different ways, thereby 

increasing flash memory longevity. 



35 5.2 Requirements of protocol 

Each QA Chip contains the following values: 

N The maximum number of keys known to the chip. 
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T The number of vectors M is broken into. 

Kn Array of N secret keys used for calculating FkoIX] where Kn is the nth element of the array. 

R Current random number used to ensure time varying messages. Each chip instance must be 
seeded with a different initial value. Changes for each signature generation. 
5 M T Array of T memory vectors. Only M 0 can be written to with an authorized write, while all Ms 
can be written to in an unauthorized write. Writes to M 0 are optimized for Flash usage, while 
updates to any other M 1+ are expensive with regards to Flash utilization, and are expected to 
be only performed once per section of M n . contains T, N and f in Readonly form so users 
of the chip can know these two values. 
1 0 P t +n T+N element array of access permissions for each part of M. Entries n={0... T-1} hold access 
permissions for non-authenticated writes to M n (no key required). Entries n={T to T+N-1}hold 
access permissions for authenticated writes to M 0 for K n . Permission choices for each part of 
M are Read Only, Read/Write, and Decrement Only. 

C 3 constants used for generating signatures. C 1f C 2 , and C 3 are constants that pad out a sub- 
1 5 message to a hashing boundary, and all 3 must be different. 

Each OA Chip contains the following private function: 

Skh[N,X] Internal function only. Returns SicnfX], the result of applying a digital signature function S to X 
based upon the appropriate key K^. The digital signature must be long enough to counter the 
chances of someone generating a random signature. The length depends on the signature 
20 scheme chosen, although the scheme chosen for the QA Chip is HMAC-SHA1, and therefore 

the length of the signature is 1 60 bits. 

Additional functions are required in certain QA Chips, but these are described as required. 

5.3 Read Protocols 

The set of read protocols describe the means by which a System reads a specific data vector Mt 
25 from a QA Chip referred to as ChipR. 

We assume that the communications link to ChipR (and therefore ChipR itself) is not trusted. If it 

were trusted, the System could simply read the data and there is no issue. Since the 

communications link to ChipR is not trusted and ChipR cannot be trusted, the System needs a way 

of authenticating the data as actually being from a real ChipR. 
30 Since the read protocol must be capable of being implemented in physical QA Chips, we cannot 

use asymmetric cryptography (for example the ChipR signs the data with a private key, and System 

validates the signature using a public key). 

This document describes two read protocols: 

o direct validation of reads 
35 o indirect validation of reads. 

5.3.1 Direct Validation of Reads 
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In a direct validation read protocol we require two OA Chips: ChipR is the OA Chip being read, and 
ChipT \s the OA Chip we entrust to tell us whether or not the data read from ChipR is trustworthy. 
The basic idea is that system asks ChipR for data, and ChipR responds with the data and a 
signature based on a secret key. System then asks ChipT whether the signature supplied by ChipR 
5 is correct. If ChipT responds that it is, then System can trust that data just read from ChipR. Every 
time data is read from ChipR, the validation procedure must be carried out. 
Direct validation requires the System to trust the communication line to ChipT. This could be 
because ChipT is in physical proximity to the System, and both System and ChipT are in a trusted 
(e.g. Silverbrook secure) environment. However, since we need to validate the read, ChipR by 
10 definition must be in a non-trusted environment. 

Each QA Chip protects its signature generation or verification mechanism by the use of a nonce. 

The protocol requires the following publicly available functions in ChipT: 
1 5 RandomQ Returns R (does not advance R). 

Test[n,X, Y, Z] Advances R and returns 1 if Sk^R^C-iIY] = Z. Otherwise returns 0. The time taken 
to calculate and compare signatures must be independent of data content. 

The protocol requires the following publicly available functions in ChipR: 
20 Read[n, t, X] Advances R, and returns R, M t , SkpIXIRIC^MJ. The time taken to calculate the 
signature must not be based on the contents of X, R, M t , or K. If t is invalid, the 
function assumes t=0. 

To read ChipR's memory M t in a validated way, System performs the following tasks: 
25 a. System calls ChipTs Random function; 

b. ChipT returns R T to System; 

c. System calls ChipR's Read function, passing in some key number n1 t the desired data vector 
number f, and R T (from b); 

d. ChipR updates R R , then calculates and returns R R , Mpt, SKni[RT|RR|Ci|MRt]; 

30 e. System calls ChipTs Test function, passing in the key to use for signature verification n2, and 
the results from d (i.e. R R , M Rt , SKnifRTlRRlC^MRt]); 
f. System checks response from ChipT. If the response is 1, then the M t read from ChipR is 
considered to be valid. If 0, then the M t read from ChipR is considered to be invalid. 

35 The choice of n1 and n2 must be such that ChipR's Km = ChipTs K^. 

The data flow for this read protocol is shown in Figure 328. 
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From the System's perspective, the protocol would take on a form like the following pseudocode: 

R T <— ChipT . Random ( ) 

R R , Mr, SIG r <- ChipR.Read{keyNumOnChipR, desiredM, R T ) 
ok <— ChipT. Test (keyNumOnChipT, R R , M R , SIG R ) 
5 If (ok = 1) 

// M R is to be trusted 
Else 

// M R is not to be trusted 
Endlf 

1 0 With regards to security, if an attacker finds out ChipR's K n1j they can replace the ChipR by a fake 
ChipR because they can create signatures. Likewise, if an attacker finds out ChipT's K^, they can 
replace the ChipR by a fake ChipR because ChipR's Km = ChipT's Moreover, they can use the 
ChipRs on any system that shares the same key. 

1 5 The only way of restricting exposure due to key reveals is to restrict the number of systems that 
match ChipR and ChipT. i.e. vary the key as much as possible. The degree to which this can be 
done will depend on the application. In the case of a PRINTER_QA acting as a ChipT, and an 
INK_QA acting as a ChipR, the same key must be used on ail systems where the particular 
INK_QA data must be validated. 

20 

In all cases, ChipR must contain sufficient information to produce a signature. Knowing (or finding 
out) this information, whatever form it is in, allows clone ChipRs to be built. 

5.3.2 Indirect Validation of Reads 
25 In a direct validation protocol (see Section 5.3.1), the System validates the correctness of data read 
from ChipR by means of a trusted chip ChipT. This is possible because ChipR and ChipT share 
some secret information. 

However, it is possible to extend trust via indirect validation. This is required when we trust ChipT, 
30 but ChipT doesn't know how to validate data from ChipR. Instead, ChipT knows how to validate 
data from Chip! (some intermediate chip) which in turn knows how to validate data from either 
another Chipl (and so on up a chain) or ChipR. Thus we have a chain of validation. 

The means of validation chains is translation of signatures. Chipl n translates signatures from higher 
35 up the chain (either Chipl^ or from ChipR at the start of the chain) into signatures capable of being 
passed to the next stage in the chain (either Chipl^ or to ChipT at the end of the chain). A given 
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Chipl can only translate signatures if it knows the key of the previous stage in the chain as well as 
the key of the next stage in the chain. 



The protocol requires the following publicly available functions in Chipl: 
5 Random n Returns R (does not advance R). 

Translate[n1 ,X, Y, 2,n2,A] Returns 1 , S^AIR^Y] and advances R if Z = S Kn i[R|X|Ci|Y]. 

Otherwise returns 0, 0. The time taken to calculate and compare 
signatures must be independent of data content. 

1 0 The data flow for this signature translation protocol is shown in Figure 329: 

Note that Rp rev is eventually Rr, and R nex t is eventually R T . In the multiple Chipl case, Rp rev is the R| 
of Chipl^ and Rnext is Ri of Chipl n+1 . The R prev of the first Chipl in the chain is R R> and the Rnext of the 
last Chipl in the chain is R T . 

15 

Assuming at least 1 ChipT, the System would need to perform the following tasks in order to read 
ChipR's memory M t in an indirectly validated way: 

a. System calls Chipl n 's Random function; 

b. Chipl 0 returns R J0 to System; 

20 c. System calls ChipR's Read function, passing in some key number nO, the desired data vector 
number f, and R !0 (from b); 

d. ChipR updates R R , then calculates and returns R R> M Rt , SKno[Rm|RR|Ci|M Rt ]; 

e. System assigns Rf* to Rp rev and SKnofRmlRRlC^MRt] to SIG prev 

f. System calls the next-chip-in-the-chain's Random function (either Chipl n +i or ChipT) 
25 g. The next-chip-in-the-chain will return Rnext to System 

h. System calls Chipl n 's Translate function, passing in n1 n (translation input key number), R prev , M^, 
SIGp rev ), n2 n (translation output key number) and the results from g (Rnext); 

i. Chipl returns testResult and SIGj to System 

j. If testResult = 0, then the validation has failed, and the M t read from ChipR is considered to be 
30 invalid. Exit with failure. 

k. If the next chip in the chain is a Chipl, assign SIG| to SIG prev and go to step f 
I. System calls ChipT's Test function, passing in n t , R P re V , M^, and SIG prev ; 

m. System calls System checks response from ChipT. If the response is 1, then the M t read from 
ChipR is considered to be valid. If 0, then the M t read from ChipR is considered to be invalid. 



35 



For the Translate function to work, Chipl n and Chipln+i must share a key. The choice of n1 and n2 in 
the protocol described must be such that Chipl n 's Kn2 = Chip^'s Km. 
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Note that Translate is essentially a "Test plus resign" function. From an implementation point of 
view the first part of Translate is identical to Test. 

Note that the use of Chipls and the translate function merely allows signatures to be transformed. At 
5 the end of the translation chain (if present) will be a ChipT requiring the use of a Test function. 

There can be any number of Chipls in the chain to ChipT as long as the Translate function is used 
to map signatures between Chipl n and Chipl^ and so on until arrival at the final destination 
(ChipT). 

1 0 From the System's perspective, a read protocol using at least 1 Chipl would take on a form like the 
following pseudocode: 

Rnext <— Chipl [0] . Random () 

Rprev/ M R# SIGp r ev <— ChipR . Read ( keyNumOnChipR , desiredM , 

Rnext ) 

15 ok = 1 

i = 0 

while ( (i < iMax) AND ok) 
For i <— 0 to iMax 
If (i = iMax) 

20 

Rnext <— ChipT . Random ( ) 
Else 

Rnext <— Chipl [i+1] . Random () 
Endlf 

ok, SIGp rev <— Chipl [i] .Translate (iKey [i] , R pr ev, M R , 
25 SIG prev , oKey[i] , 

Rnext) 

Rprev = Rnext 

If (ok = 0) 

// M R is not to be trusted 
Endlf 

30 EndFor 

ok <— ChipT. Test (keyNumOnChipT, R pre v/ M R , SIG prev ) 
If (ok = 1) 

// M R is to be trusted 
Else 

35 // Mr is not to be trusted 

Endlf 
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5.3.3 Additional Comments on Reads 

In the Memjet printing environment, certain implementations will exist where the operating 
parameters are stored in OA Chips. In this case, the system must read the data from the OA Chip 
using an appropriate read protocol. 

5 

If the connection is trusted (e.g. to a virtual OA Chip in software), a generic Read is sufficient. If the 
connection is not trusted, it is ideal that the System have a trusted ChipT in the form of software (if 
possible) or hardware (e.g. a OA Chip on board the same silicon package as the microcontroller 
and firmware). Whether implemented in software or hardware, the OA Chip should contain an 
1 0 appropriate key that is unique per print engine. Such a key setup would allow reads of print engine 
parameters and also allow indirect reads of consumables (from a consumable OA Chip). 

If the ChipT is physically separate from System (e.g. ChipT is on a board connected to System) 
System must also occasionally (based on system clock for example) call ChipT's Test function with 
1 5 bad data, expecting a 0 response. This is to reduce the possibility of someone inserting a fake 
ChipT into the system that always returns 1 for the Test function. 

5.4 Upgrade Protocols 

This set of protocols describe the means by which a System upgrades a specific data vector Mt 
20 within a OA Chip (ChipU), The data vector may contain information about the functioning of the 
device (e.g. the current maximum operating speed) or the amount of a consumable remaining. 

The updating of M t in ChipU falls into two categories: 

o non-authenticated writes, where anyone is able to update the data vector 
25 o authenticated writes, where only authorized entities are able to upgrades data vectors 

5.4.1 Non-authenticated writes 

This is the most frequent type of write, and takes place between the System / consumable during 
normal everyday operation for M 0 , and during the manufacturing process for M 1+ . 

30 

In this kind of write, the System wants to change M t within ChipU subject to P. For example, the 
System could be decrementing the amount of consumable remaining. Although System does not 
need to know and of the Ks or even have access to a trusted chip to perform the write, the System 
must follow a non-authenticated write by an authenticated read if it needs to know that the write was 
35 successful. 
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The protocol requires ChipU to contain the following publicly available function: 

Write[t, X] Writes X over those parts of M t subject to P t and the existing value for M. 

To authenticate a write of Mnew to ChipA's memory M: 
a. System calls ChipLTs Write function, passing in Mnew; 
5 b. The authentication procedure for a Read is carried out (see Section 5.3 on page 604); 

c. If the read succeeds in such a way that M^w = M returned in b, the write succeeded. If not, it 
failed. 

Note that if these parameters are transmitted over an error-prone communications line (as opposed 
10 to internally or using an additional error-free transport layer), then an additional checksum would be 
required to prevent the wrong M from being updated or to prevent the correct M from being updated 
to the wrong value. For example, SHA-1[t,X] should be additionally transferred across the 
communications line and checked (either by a wrapper function around Write or in a variant of Write 
that takes a hash as an extra parameter). 

15 

This is the most frequent type of write, and takes place between the System / consumable during 
normal everyday operation for M 0 , and during the manufacturing process for M 1+ . 

5.4.2 Authenticated writes 
20 In the QA Chip protocols, M 0 is defined to be the only data vector that can be upgraded in an 

authenticated way. This decision was made primarily to simplify flash management, although it also 
helps to reduce the permissions storage requirements. 

In this kind of write, System wants to change Chip ITs M 0 in an authorized way, without being 
25 subject to the permissions that apply during normal operation. For example, a consumable may be 
at a refilling station and the normally Decrement Only section of M 0 should be updated to include 
the new valid consumable. In this case, the chip whose M 0 is being updated must authenticate the 
writes being generated by the external System and in addition, apply the appropriate permission for 
the key to ensure that only the correct parts of M 0 are updated. Having a different permission for 
30 each key is required as when multiple keys are involved, all keys should not necessarily be given 
open access to M 0 . For example, suppose M 0 contains printer speed and a counter of money 
available for franking. A ChipS that updates printer speed should not be capable of updating the 
amount of money. Since P 0 ..t-i is used for non-authenticated writes, each K n has a corresponding 
permission P T+n that determines what can be updated in an authenticated write. 

35 

The basic principle of the authenticated write (or upgrade) protocol is that the new value for the M t 
must be signed before ChipU accepts it. The QA Chip responsible for generating the signature 
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(ChipS) must first validate that the ChipU is valid by reading the old value for M t . Once the old value 
is seen as valid, a new value can be signed by ChipS and the resultant data plus signature passed 
to ChipU. Note that both chips distrust each other. 
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There are two forms of authenticated writes. The first form is when both ChipU and ChipS directly 
store the same key. The second is when both ChipU and ChipS store different versions of the key 
and a transforming procedure is used on the stored key to generate the required key - i.e. the key is 
indirectly stored. The second form is slightly more complicated, and only has value when the ChipS 
is not readily available to an attacker. 



5. 4. 2. 1 Direct authenticated writes 

The direct form of the authenticated write protocol is used when the ChipS and ChipU are equally 
available to an attacker. For example, suppose that ChipU contains a printer's operating speed. 
Suppose that the speed can be increased by purchasing a ChipS and inserting it into the printer 
1 5 system. In this case, the ChipS and ChipU are equally available to an attacker. This is different from 
upgrading the printer over the internet where the effective ChipS is in a remote location, and 
thereby not as readily available to an attacker. 

The direct authenticated write protocol requires ChipU to contain the following publicly available 
20 functions: 

Read[n, t, X] Advances R, and returns R, M t , S Kn [X|R|Ci|Mt]. The time taken to calculate the 
signature must not be based on the contents of X, R, M t , or K. 

WriteA[n, X, Y, Z] Advances R, replaces M 0 by Y subject to P T+n , and returns 1 only if Sk^MC^Y] 
25 = Z. Otherwise returns 0. The time taken to calculate and compare signatures 

must be independent of data content. This function is identical to ChipTs Test 
function except that it additionally writes Y subject to P T+n to its M when the 
signature matches. 

Authenticated writes require that the System has access to a ChipS that is capable of generating 
30 appropriate signatures. 

In its basic form, ChipS requires the following variables and function: 

SignMfn.V.W.X.^Z] Advances R, and returns R, SKn[W|R|Ci|Z] only if Y = SnJVIWIdpg. 

Otherwise returns all 0s. The time taken to calculate and compare signatures must 
35 be independent of data content. 

To update ChipU's M vector: 
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a. System calls ChipU's Read function, passing in n1 , 0 (desired vector number) and 0 (the random 
value, but is a don't-care value) as the input parameters; 

b. ChipU produces Ry, M uo , SKni[0|Ru|Ci|M uo ] and returns these to System; 

c. System calls ChipS's SignM function, passing in n2 (the key to be used in ChipS), 0 (the random 
5 value as used in a), Ry, M uo , S K ni[0|Ru|Ci|M uo ], and M D (the desired vector to be written to 

ChipU); 

d. ChipS produces R s and S Kn 2[Ru|Rs|Ci|M D ] if the inputs were valid, and 0 for all outputs if the 
inputs were not valid. 

e. If values returned in d are non zero, then ChipU is considered authentic. System can then call 
1 0 ChipU's WriteA function with these values from d. 

f. ChipU should return a 1 to indicate success. A 0 should only be returned if the data generated 
by ChipS is incorrect (e.g. a transmission error). 

The choice of n1 and n2 must be such that ChipU's K n1 = ChipS's K^. 

15 

The data flow for authenticated writes is shown in Figure 330. 

Note that this protocol allows ChipS to generate a signature for any desired memory vector MD, and 
therefore a stolen ChipS has the ability to effectively render the particular keys for those parts of M 0 
20 in ChipU irrelevant. 

It is therefore not recommended that the basic form of ChipS be ever implemented except in 
specifically controlled circumstances. 

25 It is much more secure to limit the powers of ChipS. The following list covers some of the variants of 
limiting the power of ChipS: 

a. the ability to upgrade a limited number of times 

b. the ability to upgrade based on a credit value - i.e. the upgrade amount is decremented from the 
local value, and effectively transferred to the upgraded device 

30 c. the ability to upgrade to a fixed value or from a limited list 

d. the ability to upgrade to any value 

e. the ability to only upgrade certain data fields within M 

In many of these variants, the ability to refresh the ChipS in some way (e.g. with a new count or 
35 credit value) would be a useful feature. 
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In certain cases, the variant is in ChipS, while ChipU remains the same. It may also be desirable to 
create a ChipU variant, for example only allowing ChipU to only be upgraded a specific number of 
times. 



5 5.4.2.1.1 Variant example 

This section details the variant for the ability to upgrade a memory vector to any value a specific 
number of times, but the upgrade is only allowed to affect certain fields within the memory vector 
i.e. a combination of (a), (d), and (e) above. 

10 In this example, ChipS requires the following variables and function: 

CountRemaining Part of ChipS's M 0 that contains the number of signatures that ChipS is 
allowed to generate. Decrements with each successful call to SignM and 
SignP. Permissions in ChipS's P 0 .. T -i for this part of M 0 needs to be Readonly 
once ChipS has been setup. Therefore CountRemaining can only be updated 

15 by another ChipS that will perform updates to that part of M 0 (assuming 

ChipS's Ps allows that part of M 0 to be updated). 
Q Part of M that contains the write permissions for updating ChipU's M. By 

adding Q to ChipS we allow different ChipSs that can update different parts 
of My. Permissions in ChipS's Po.t-i for this part of M needs to be Readonly 

20 once ChipS has been setup. Therefore Q can only be updated by another 

ChipS that will perform updates to that part of M. 
SignM[n,V,W,X,Y,Z] Advances R f decrements CountRemaining and returns R, Zqx (Z applied to X 
with permissions Q), SKnfWIRIdlZox] only if Y = SKnfVIWIdIX] and 
CountRemaining > 0. Otherwise returns all 0s. The time taken to calculate 

25 and compare signatures must be independent of data content. 

To update ChipU's M vector: 

a. System calls ChipU's Read function, passing in n1, 0 (desired vector number) and 0 (the random 
value, but is a don't-care value) as the input parameters; 
30 b. ChipU produces R Ut M uo , S K ni[0|Ru|Ci|M uo ] and returns these to System; 

c. System calls ChipS's SignM function, passing in n2 (the key to be used in ChipS), 0 (as used in 
a), Ru, M uo , SjcnilOIRulCilMuoL and M D (the desired vector to be written to ChipU); 

d. ChipS produces R S( M QD (processed by running M D against M u0 using Q) and Sk^RuIRsIC-iIMcid] 
if the inputs were valid, and 0 for all outputs if the inputs were not valid. 

35 e. If values returned in d are non zero, then ChipU is considered authentic. System can then call 
ChipU's WriteA function with these values from d. 
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f. ChipU should return a 1 to indicate success. A 0 should only be returned if the data generated 
by ChipS is incorrect (e.g. a transmission error). 

The choice of n1 and n2 must be such that ChipU's Km = ChipS's K^. 

5 

The data flow for this variant of authenticated writes is shown in Figure 331 . 

Note that Q in ChipS is part of ChipS's M. This allows a user to set up ChipS with a permission set 
for upgrades. This should be done to ChipS and that part of M designated by P 0 ..t-i set to Readonly 
1 0 before ChipS is programmed with Ky. If Ks is programmed with Ku first, there is a risk of someone 
obtaining a half-setup ChipS and changing all of Mu instead of only the sections specified by Q. 

In addition, CountRemaining in ChipS needs to be setup (including making it Readonly in P s ) 
before ChipS is programmed with Ku. ChipS should therefore be programmed to only perform a 
1 5 limited number of SignM operations (thereby limiting compromise exposure if a ChipS is stolen). 
Thus ChipS would itself need to be upgraded with a new CountRemaining every so often. 

5. 4. 2. 2 Indirect authenticated writes 

This section describes an alternative authenticated write protocol when ChipU is more readily 
20 available to an attacker and ChipS is less available to an attacker. We can store different keys on 

ChipU and ChipS, and implement a mapping between them in such a way that if the attacker is able 
to obtain a key from a given ChipU, they cannot upgrade all ChipUs. 

In the general case, this is accomplished by storing key Ks on ChipS, and Ku and f on ChipU. The 
25 relationship is f(Ks) = K y such that knowledge of Ku and f does not make it easy to determine Ks. 
This implies that a one-way function is desirable for f. 

In the OA Chip domain, we define fas a number (e.g. 32-bits) such that SHA1(Ks | f) = Ky. The 
value of f (random between chips) can be stored in a known location within as a constant for the 
30 life of the OA Chip. It is possible to use the same f for multiple relationships if desired, since f is 
public and the protection lies in the fact that f varies between OA Chips (preferably in a non- 
predictable way). 

The indirect protocol is the same as the direct protocol with the exception that f is additionally 
35 passed in to the SignM function so that ChipS is able to generate the correct key. The System 

obtains f by performing a Read of M 1a Note that all other functions, including the WriteA function in 
ChipU, are identical to their direct authentication counterparts. 
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SignM[f,n,V,W,X,Y,Z] Advances R, and returns R, S^tWIRIdlZ] only if Y = S^MWIdpq 
and CountRemaining > 0. Otherwise returns all 0s. The time taken to calculate and 
compare signatures must be independent of data content. 

5 Before reading ChipU's memory M 0 (the pre-upgrade value), the System must extract f from ChipU 
by performing the following tasks: 

a. System calls ChipU's Read function, passing in (dontCare, 1, dontCare) 

b. ChipU returns M 1f from which System can extract fu 

c. System stores f u for future use 

10 

To update ChipU's M vector, the protocol is identical to that described in the basic authenticated 
write protocol with the exception of steps c and d: 

c. System calls ChipS's SignM function, passing in f y , n2 (the key to be used in ChipS), 0 (as used 
in a), Ry, M uo , S K ni[0|Ru|Ci|M uo ], and M D (the desired vector to be written to ChipU); 
15 d. ChipS produces Rs and Sfu(Kn2)[Ru|Rs|Ci|M D ] if the inputs were valid, and 0 for all outputs if the 
inputs were not valid. 

In addition, the choice of n1 and n2 must be such that ChipU's K n i = ChipS's fu(Kn 2 ). 

20 Note that fu is obtained from hA^ without validation. This is because there is nothing to be gained by 
subverting the value of f Uf (because then the signatures won't match). 

From the System's perspective, the protocol would take on a form like the following pseudocode: 
dontCare, M R/ dontCare <- ChipR . Read (dontCare, 1 , dontCare) 
25 f R = extract from M R 

Ru/ M u# SIGu <— ChipU. Read (keyNumOnChipU, 0 , 0) 

R s , SIG S = ChipS. SignM2 (f R/ keyNumOnChipS , 0, Ru, Mu, SIGu, M D ) 
If (R s = SIG S = 0) 
30 // ChipU and therefore Mu is not to be trusted 

Else 

// ChipU and therefore M n can be trusted 

ok = ChipU. Writ eA (keyNumOnChipU, R s , M D , SIG S ) 

If (ok) 

35 // updating of data in ChipU was successful 

Else 

// transmission error during WriteA 
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Endlf 
Endlf 

5.4.2.2.1 variant example 
5 The indirect form of the example from Section 5.4.2.1 .1 is shown here. 

SignM[f t n,V,W f X t Y,Z] Advances R, decrements CountRemaining and returns R, Zqx (Z applied to X 
with permissions Q), S^IWIRIdlZox] only if Y = Sf^MWIC^X] and 
CountRemaining > 0. Otherwise returns all 0s. The time taken to calculate and 
compare signatures must be independent of data content. 

10 

Before reading ChipU's memory M 0 (the pre-upgrade value), the System must extract f from ChipU 
by performing the following tasks: 

a. System calls ChipU's Read function, passing in (dontCare, 1 , dontCare) 

b. ChipU returns M 1f from which System can extract fu 
15 c. System stores fu for future use 

To update ChipU's M vector, the protocol is identical to that described in the basic authenticated 
write protocol with the exception of steps c and d: 

c. System calls ChipS's SignM function, passing in fy, n2 (the key to be used in ChipS), 0 (as used 
20 in a), R Uf Muo, SKnitOjRulCilMuo], and M D (the desired vector to be written to ChipU); 

d. ChipS produces Rs, M QD (processed by running M D against M u0 using Q) and 
Sfu(Kn2)[Ru|Rs|Ci|M QD ] if the inputs were valid, and 0 for all outputs if the inputs were not valid. 

In addition, the choice of n1 and n2 must be such that ChipU's K n i = ChipS's fu(Kn2). 

25 

Note that fy is obtained from M 1 without validation. This is because there is nothing to be gained by 
subverting the value of fu, (because then the signatures won't match). 

From the System's perspective, the protocol would take on a form like the following pseudocode: 
dontCare, M R , dontCare <— ChipR . Read (dontCare , 1 , dontCare) , 
f R = extract from M R 

Ru, Mu, SIGu <— ChipU. Read (keyNumOnChipU, 0, 0) 

Rs# Mqd* SIG s = ChipS . SignM2 (f R/ keyNumOnChipS , 0, R<j, Mq, SIGu, M D ) 
If (R s = Mq D = SIGs = 0) 

// ChipU and therefore Mu is not to be trusted 
Else 
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// ChipU and therefore Mu can be trusted 

ok = ChipU. Writ eA (keyNumOnChipU, R s , Mq D , SIG s ) 

If (ok) 

// updating of data in ChipU was successful 
5 Else 

// transmission error during WriteA 
Endlf 
Endlf 



1 0 5.4.3 Updating permissions for future writes 

In order to reduce exposure to accidental and malicious attacks on P (and certain parts of M), only 
authorized users are allowed to update P. Writes to P are the same as authorized writes to M, 
except that they update P n instead of M. Initially (at manufacture), P is set to be Read/Write for all 
M. As different processes fill up different parts of M, they can be sealed against future change by 

1 5 updating the permissions. Updating a chip's Po.t-i changes permissions for unauthorized writes to 
M n , and updating P t ..t+n-i changes permissions for authorized writes with key K n . 



P n is only allowed to change to be a more restrictive form of itself. For example, initially all parts of 
M have permissions of Read/Write. A permission of Read/Write can be updated to Decrement Only 
20 or Read Only. A permission of Decrement Only can be updated to become Read Only. A Read Only 
permission cannot be further restricted. 

In this transaction protocol, the System's chip is referred to as ChipS, and the chip being updated is 
referred to as ChipU. Each chip distrusts the other. 

25 

The protocol requires the following publicly available functions in ChipU: 
Random □ Returns R (does not advance R). 

SetPermission[n,p,X,Y,Z] Advances R, and updates P p according to Y and returns 1 followed by 
the resultant P p only if S Kn [R|X|Y|C 2 ] = Z. Otherwise returns 0. P p can only become 
30 more restricted. Passing in 0 for any permission leaves it unchanged (passing in 

Y=0 returns the current P p ). 



Authenticated writes of permissions require that the System has access to a ChipS that is capable 
of generating appropriate signatures. ChipS requires the following variable: 
35 CountRemaining Part of ChipS's M 0 that contains the number of signatures that ChipS is 

allowed to generate. Decrements with each successful call to SignM and 
SignP. Permissions in ChipS's P 0 .. T -i for t h 'S part of M 0 needs to be Readonly 
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once ChipS has been setup. Therefore CountRemaining can only be updated 
by another ChipS that will perform updates to that part of M 0 (assuming 
ChipS's P n allows that part of M 0 to be updated). 



5 In addition, ChipS requires either of the following two SignP functions depending on whether direct 
or indirect key storage is used (see direct vs indirect authenticated write protocols in Section 5.4.2): 
SignP[n,X,Y] Used when the same key is directly stored in both ChipS and ChipU. Advances R, 
decrements CountRemaining and returns R and S Kn [X|R|Y|C 2 ] only if 
CountRemaining > 0. Otherwise returns all 0s. The time taken to calculate and 
1 0 compare signatures must be independent of data content. 

SignP[f,n,X,Y] Used when the same key is not directly stored in both ChipS and ChipU. In this 
case ChipU's K n i = ChipS's f(Kn2). The function is identical to the direct form of 
SignP, except that it additionally accepts f and returns S^Kn)[X|R|Y|C 2 ] instead of 
S K n[X|R|Y|C 2 ]. 

15 

5. 4. 3. 1 Direct form of SignP 

When the direct form of SignP is used, ChipU's P n is updated as follows: 

a. System calls ChipU's Random function; 

b. ChipU returns R u to System; 

20 c. System calls ChipS's SignP function, passing in n2, Ru and P D (the desired P to be written to 
ChipU); 

d. ChipS produces R s and S Kn 2[Ru|Rs|PD|C 2 ] if it is still permitted to produce signatures. 

e. If values returned in d are non zero, then System can then call ChipU's SetPermission function 
with n1 , the desired permission entry p, R s , Pd and S K n2[Ru|RsPD|C 2 ]. 

25 f. ChipU verifies the received signature against its own generated signature S K ni[Ru|Rs|Po|C 2 ] and 
applies P D to P n if the signature matches 
g. System checks 1st output parameter. 1 = success, 0 = failure. 

The choice of n1 and n2 must be such that ChipU's K n i = ChipS's K^. 

30 

The data flow for basic authenticated writes to permissions is shown in Figure 332. 

5. 4. 3. 2 indirect form of SignP 

When the indirect form of SignP is used in ChipS, the System must extract f from ChipU (so it 
35 knows how to generate the correct key) by performing the following tasks: 

a. System calls ChipU's Read function, passing in (dontCare, 1, dontCare) 

b. ChipU returns M 1( from which System can extract fy 
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c. System stores fu for future use 



ChipU's P n is updated as follows: 
a. System calls ChipU's Random function; 
5 b. ChipU returns Ru to System; 

c. System calls ChipS's SignP function, passing in fy, n2, Ru and P D (the desired P to be written to 
ChipU); 

d. ChipS produces Rs and Sflj(Kn2)[Ru|Rs|Po|C2] if it is still permitted to produce signatures. 

e. If values returned in d are non zero, then System can then call ChipU's SetPermission function 
10 with n1, the desired permission entry p, R s , P D and Sfu(Kn2)[Ru|Rs|PD|C 2 ]. 

f. ChipU verifies the received signature against SKni[Ru|Rs|PD|C 2 ] and applies P D to P n if the 
signature matches 

g. System checks 1st output parameter. 1 = success, 0 = failure. 

In addition, the choice of n1 and n2 must be such that ChipU's Kni = ChipS's fufK,*). 
1 5 5.4.4 Protecting memory vectors 

To protect the appropriate part of M n against unauthorized writes, call SetPermissions[n] for n = 0 to 
T-1 . To protect the appropriate part of M 0 against authorized writes with key n, call 
SetPermissions[T+n] for n=0 to N-1 . 

Note that only M 0 can be written in an authenticated fashion. 
20 Note that the SetPermission function must be called after the part of M has been set to the desired 
value. 

For example, if adding a serial number to an area of Mi that is currently ReadWrite so that noone is 
permitted to update the number again: 

o the Write function is called to write the serial number to Mi 
25 © SetPermission(1 ) is called for to set that part of M to be Readonly for non-authorized writes. 
If adding a consumable value to M 0 such that only keys 1-2 can update it, and keys 0, and 3-N 
cannot: 

o the Write function is called to write the amount of consumable to M 

o SetPermission is called for 0 to set that part of M 0 to be DecrementOnly for non-authorized 
30 writes. This allows the amount of consumable to decrement. 

o SetPermission is called for n = {T, T+3, T+4 T+N-1} to set that part of M 0 to be Readonly 

for authorized writes using all but keys 1 and 2. This leaves keys 1 and 2 with ReadWrite 

permissions to M 0 . 

It is possible for someone who knows a key to further restrict other keys, but it is not in anyone's 
35 interest to do so. 

5.5 Programming K 
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In this case, we have a factory chip (ChipF) connected to a System. The System wants to program 
the key in another chip (ChipP). System wants to avoid passing the new key to ChipP in the clear, 
and also wants to avoid the possibility of the key-upgrade message being replayed on another 
ChipP (even if the user doesn't know the key). 

5 

The protocol assumes that ChipF and ChipP already share (directly or indirectly) a secret key Ko fd . 
This key is used to ensure that only a chip that knows Kow can set Knew- 

Although the example shows a ChipF that is only allowed to program a specific number of ChipPs, 
1 0 the key-upgrade protocol can be easily altered (similar to the way the write protocols have variants) 
to provide other means of limiting the ability to update ChipPs. 

The protocol requires the following publicly available functions in ChipP: 
Random 0 Returns R (does not advance R). 
1 5 ReplaceKey[n, X, Y, Z] Replaces K n by S Kn [R|X|C 3 ]©Y, advances R, and returns 1 

only if S Kn [X|Y|C 3 ] = Z. Otherwise returns 0. The time taken to calculate signatures 
and compare values must be identical for all inputs. 

And the following data and functions in ChipF: 
20 CountRemaining Part of M 0 with contains the number of signatures that ChipF is allowed to 

generate. Decrements with each successful call to GetProgramKey. Permissions in 
P for this part of M 0 needs to be Readonly once ChipF has been setup. Therefore 
can only be updated by a Chips that has authority to perform updates to that part of 
M 0 . 

25 Knew The new key to be transferred from ChipF to ChipP. Must not be visible. After 

manufacture, K new is 0. 

SetPartialKey[X] Updates K^w to be K ne w®X. This function allows Knew to be programmed in any 
number of steps, thereby allowing different people or systems to know different parts of the key (but 
30 not the whole Knew). Knew is stored in ChipF's flash memory. 

In addition, ChipF requires either of the following GetProgramKey functions depending on whether 
direct or indirect key storage is used on the input key and/or output key (see direct vs indirect 
authenticated write protocols in Section 5.4.2): 
35 GetProgramKeyl [n, X] Direct to direct. Used when the same key (Kn) is directly stored in both 

ChipF and ChipP and we want to store Knew in ChipP. Advances Rp, decrements 
CountRemaining, outputs R F , the encrypted key SKntXIRplCaPKnew and a 
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signature of the first two outputs plus C 3 if CountRemaining>0. Otherwise outputs 
0. The time to calculate the encrypted key & signature must be identical for all 
inputs. 

GetProgramKey2[f, n, X] Direct to indirect. Used when the same key (Kn) is directly stored in 
5 both ChipF and ChipP but we want to store fp(Knew) in ChipP instead of simply 

Knew (i.e. we want to keep the key in ChipP to be different in all ChipPs). In this 
case ChipP's K n1 = ChipF's f P (Kn2). The function is identical to GetProgramKeyl, 
except that it additionally accepts f P , and returns SKn[X|RF|C 3 ]©fp(Knew) instead of 
SKn[X|R F |C 3 ] ©Knew- Note that the produced signature is produced using Kn since 

1 0 that is what is already stored in ChipP. 

GetProgramKey3[f, n, X] Indirect to direct. Used when the same key is not directly stored in both 
ChipF and ChipP but we want to store Knew in ChipP. In this case ChipP's Km = 
ChipF's f P (Kn2). The function is identical to GetProgramKeyl, except that it 
additionally accepts f P , and returns Sfp (K n)[X|RF|C 3 ]©Knew instead of 

1 5 S K n[X|RF|C3]©Knew. The produced signature is produced using f P (Kn) instead of K„ 

since that is what is already stored in ChipP. 
GetProgramKey4[f, n, X] Indirect to indirect. Used when the same key is not directly stored in both 
ChipF and ChipP but we want to store fp(K ne w) in ChipP instead of simply Knew (i ©- 
we want to keep the key in ChipP to be different in ail ChipPs). In this case 

20 ChipP's Km = ChipF's fpfK^). The function is identical to GetProgramKey3, except 

that it returns Sfp (K n)[X|RF|C 3 ]©fp(Knew) instead of Sfp ( Kn)[X|RF|C 3 ]©Knew. The pro- 
duced signature is produced using f P (K n ) since that is what is already stored in 
ChipP. 

25 Since there are likely to be few ChipFs, and many ChipPs, the indirect forms of GetProgramKey can 
be usefully employed. 

5.5.1 GetProgramKeyl - direct to direct 

With the "old key = direct, new key = direct" form of GetProgramKey, to update P's key : 
30 a. System calls ChipPs Random function; 

b. ChipP returns Rp to System; 

c. System calls ChipFs GetProgramKey function, passing in n2 (the desired key to use) and the 
result from b; 

d. ChipF updates Rp, then calculates and returns R F , S^tRplRFlCalSKnew, and 

35 SKn2[RF|S|<n2[Rp|RF|C3]0Knew|C3]; 

e. If the response from d is not 0, System calls ChipP's ReplaceKey function, passing in n1 (the 
key to use in ChipP) and the response from d; 
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f. System checks response from ChipP. If the response is 1 , then ChipPs Km has been correctly 
updated to K^. If the response is 0, ChipPs Km has not been updated. 

The choice of n1 and n2 must be such that ChipPs Km = ChipF's K^. 

5 

The data flow for key updates is shown in Figure 333: 

Note that Knew is never passed in the open. An attacker could send its own Rp, but cannot produce 
SKn2[Rp|RF|C 3 ] without Kn2. The signature based on K^ is sent to ensure that ChipP will be able to 
1 0 determine if either of the first two parameters have been changed en route. 

CountRemaining needs to be setup in M F0 (including making it Readonly in P) before ChipF is 
programmed with K P . ChipF should therefore be programmed to only perform a limited number of 
GetProgramKey operations (thereby limiting compromise exposure if a ChipF is stolen). An 
1 5 authorized ChipS can be used to update this counter if necessary (see Section 5.4.2 on page 610). 

5.5.2 GetProgramKey2 - direct to indirect 

With the "old key = direct, new key = indirect" form of GetProgramKey, to update Ps key, the 
System must extract f from ChipP (so it can tell ChipF how to generate the correct key) by 
20 performing the following tasks: 

a. System calls ChipP's Read function, passing in (dontCare, 1 , dontCare) 

b. ChipP returns M 1f from which System can extract f P 

c. System stores f P for future use 

25 ChipPs key is updated as follows: 

a. System calls ChipPs Random function; 

b. ChipP returns R P to System; 

c. System calls ChipF's GetProgramKey function, passing in f P , n2 (the desired key to use) and the 
result from b; 

30 d. ChipF updates Rp, then calculates and returns R F , S K n2[Rp|RF|C 3 ]©f P (Knew), and 

SKn2 [f^F |Skti2[Rp I I Ca]©f P ( Knew) IC3] ; 

e. If the response from d is not 0, System calls ChipP's ReplaceKey function, passing in n1 (the 
key to use in ChipP) and the response from d; 

f. System checks response from ChipP. If the response is 1 , then ChipP's Km has been correctly 
35 updated to f P (Knew). If the response is 0, ChipP's Km has not been updated. 

The choice of n1 and n2 must be such that ChipP's Km = ChipF's K^. 



622 



5.5.3 GetProgramKey3 - indirect to direct 

With the "old key = indirect, new key = direct" form of GetProgramKey, to update P's key, the 
System must extract f from ChipP (so it can tell ChipF how to generate the correct key) by 
5 performing the following tasks: 

a. System calls ChipP's Read function, passing in (dontCare, 1, dontCare) 

b. ChipP returns M 1v from which System can extract f P 

c. System stores f P for future use 

1 0 ChipP's key is updated as follows: 

a. System calls ChipP's Random function; 

b. ChipP returns R P to System; 

c. System calls ChipF's GetProgramKey function, passing in f Pl n2 (the desired key to use) and the 
result from b; 

15 d. ChipF updates R F , then calculates and returns R F , Sf^Kn^tRplRplCajeKnew, and 

SfP(Kn2)[RF|SfP(Kn2)[RpRF|C3]0Knew|C3]; 

e. If the response from d is not 0, System calls ChipP's ReplaceKey function, passing in n1 (the 
key to use in ChipP) and the response from d; 

f. System checks response from ChipP. If the response is 1 , then ChipP's K n1 has been correctly 
20 updated to K new . If the response is 0, ChipP's Km has not been updated. 

The choice of n1 and n2 must be such that ChipP's K n1 = ChipF's f^K^). 

5.5.4 GetProgramKey4 - indirect to indirect 

With the "old key = indirect, new key = indirect" form of GetProgramKey, to update P's key, the 
25 System must extract f from ChipP (so it can tell ChipF how to generate the correct key) by 
performing the following tasks: 

a. System calls ChipP's Read function, passing in (dontCare, 1 , dontCare) 

b. ChipP returns M 1v from which System can extract f P 

c. System stores f P for future use 

30 

ChipP's key is updated as follows: 

a. System calls ChipP's Random function; 

b. ChipP returns Rp to System; 

c. System calls ChipF's GetProgramKey function, passing in f P , n2 (the desired key to use) and the 
35 result from b; 

d. ChipF updates Rr, then calculates and returns R F , S^Kr^jtRplRFlCajef^Knew), and 

SfP(Kn2)[RF |Sfp(Kn2)[Rp| Rp|C 3 ]©f P ( Knew)^] ; 
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e. If the response from d is not 0, System calls ChipP's ReplaceKey function, passing in n1 (the 
key to use in ChipP) and the response from d; 

f. System checks response from ChipP. If the response is 1, then ChipP's Km has been correctly 
updated to fp(Kne W ). If the response is 0, ChipP's Km has not been updated. 

5 The choice of n1 and n2 must be such that ChipP's Km = ChipF's fpfK,*). 

5.5.5 Chicken and Egg 

The Program Key protocol requires both ChipF and ChipP to know Koi d (either directly or indirectly). 
Obviously both chips had to be programmed in some way with Ko, d , and thus Kqw can be thought of 
10 as an older K^: Koi d can be placed in chips if another ChipF knows Koi der , and so on. 

Although this process allows a chain of reprogramming of keys, with each stage secure, at some 
stage the very first key (K firet ) must be placed in the chips. K first is in fact programmed with the chip's 
microcode at the manufacturing test station as the last step in manufacturing test. K first can be a 

1 5 manufacturing batch key, changed for each batch or for each customer etc., and can have as short 
a life as desired. Compromising K first need not result in a complete compromise of the chain of Ks. 
This is especially true if K first is indirectly stored in ChipPs (i.e. each ChipP holds an f and f(K firet ) 
instead of K first directly). One example is where K first (the key stored in each chip after 
manufacture/test) is a batch key, and can be different per chip. K first may advance to a ComCo 

20 specific Ksecond etc. but still remain indirect. A direct form (e.g. K fina i) only needs to go in if it is 
actually required at the end of the programming chain. 

Depending on reprogramming requirements, K first can be the same or different for all K n . 

25 6 Memjet forms of Protocols 

Physical OA Chips are used in Memjet printer systems to store printer operating parameters as well 
as consumable parameters. 

6.1 PRINTER_QA 
30 A PRINTER_QA is stored within each print engine to perform two primary tasks: 
o storage and protection of operating parameters 
o a means of indirect read validation of other OA Chip data vectors 
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Each PRINTER_QA contains the following keys: 
Table 229. Keys in PrinterQA 



Key 


Contents 


Comments 


0 


Upgrade Key 


Used to upgrade the operating 
parameters. Should be indirect form 
of key (i.e. a different key for each 
PRINTER_QA) so that an indirect 
form of the write is required. 


1 


Consumable Read Validation Key 


Used to indirectly read the data from 
an CONSUMABLE_QA chip using 
indirect authenticated read protocol ( 
Section 5.3.2 on page 606). 


2 


PrintEngineController Read 
Validation Key 


When reading data from the 
PRINTER_QA, the system can either 
trust the data, or must use this key to 
perform the authenticated read 
protocol (see Section 5.3 on page 
604). 


3-n 


(reserved) 


Currently unused. 

Could be used to provide a means to 
indirectly read additional print engine 
operating parameters ala K1 , or 
provide additional Print Engine 
validation ala K2. 



5 

Note that if multiple Print Engine Controllers are used (e.g. a multiple SoPEC system), then multiple 
PrintEngineController Read Validation Keys are required. These keys can be stored within a single 
PRINTER_QA (e.g. in K 3 and beyond), or can be stored in separate PRINTER_QAs (for example 
each SoPEC (or group of SoPECs) has an individual PRINTER_QA). 

10 

The functions required in the PRINTER_QA are: 
o Random, ReplaceKey, to allow key programming & substitution 
o Read, to allow reads of data 
o Write, to allow updates of M 1+ during manufacture 
15 o WriteAuth, to provide a means of updating the M 0 data (operating parameters) 
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© SetPermissions, to provide a means of updating write permissions 
o Test, to provide a means of checking if consumable reads are valid 
o Translate, to provide a means of indirect reading of consumable data 



5 6.2 CONSUMABLE_QA 

A CONSUMABLE_QA is stored with each consumable (e.g. ink cartridge) to perform two primary 
tasks: 

o storage of consumable related data 

o protection of consumable amount remaining 

10 

Each CONSUMABLE_QA contains the following keys: 
Table 230. Keys in CONSUMABLE_QA 



Key 


Contents 


Comments 


0 


Upgrade Key 


Used to upgrade the consumable 
parameters. Should be stored as the 
indirect form of the key (i.e. a 
different key for each 
CONSUMABLEJ3A) so that an 
indirect form of the write is required. 


1 


Consumable Read Validation Key 


When reading data from the 
CONSUMABLE_QA, the system can 
either trust the data, or must use this 
key to perform either the direct or 
indirect authenticated read protocol 
(see Section 5.3 on page 604). 


2 


(reserved) 


Currently unused. 


3-n 


(reserved) 


Currently unused. 



1 5 The functions required in the CONSUMABLE_QA are: 

o Random, ReplaceKey, to allow key programming & substitution 

o Read, to allow reads of data 

o Write, to allow updates of M 1+ during manufacture 

o WriteAuth, to provide a means of updating the M 0 data (consumable remaining) 
20 © SetPermissions, to provide a means of updating write permissions 
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AUTHENTICATION OF CONSUMABLES 



1 Introduction 

Manufacturers of systems that require consumables (such as a laser printer that requires toner 
5 cartridges) have struggled with the problem of authenticating consumables, to varying levels of 

success. Most have resorted to specialized packaging that involves a patent. However this does not 
stop home refill operations or clone manufacture in countries with weak industrial property 
protection. The prevention of copying is important to prevent poorly manufactured substitute 
consumables from damaging the base system. For example, poorly filtered ink may clog print 
1 0 nozzles in an ink jet printer, causing the consumer to blame the system manufacturer and not admit 
the use of non-authorized consumables. 

To solve the authentication problem, this document describes an OA Chip that contains 
authentication keys and circuitry specially designed to prevent copying. The chip is manufactured 
1 5 using the standard Flash memory manufacturing process, and is low cost enough to be included in 
consumables such as ink and toner cartridges. The implementation is approximately 1mm 2 in a 
0.25 micron flash process, and has an expected manufacturing cost of approximately 10 cents in 
2003. 

20 2 NSA 

Once programmed, the QA Chips as described here are compliant with the NSA export guidelines 
since they do not constitute a strong encryption device. They can therefore be practically 
manufactured in the USA (and exported) or anywhere else in the world. 

25 3 Nomenclature 

The following symbolic nomenclature is used throughout this document: 
Table 231 . Summary of symbolic nomenclature 



Symbol 


Description 


F[X] 


Function F, taking a single parameter X 


F[X,Y] 


Function F, taking two parameters, X and Y 


X | Y 


X concatenated with Y 


XaY 


Bitwise X AND Y 


X v Y 


Bitwise X OR Y (inclusive-OR) 


xe y 


Bitwise X XOR Y (exclusive-OR) 


-X 


Bitwise NOT X (complement) 
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X <- Y 


X is assigned the value Y 


X<-{Y, Z} 


The domain of assignment inputs to X is Y and 2 


X = Y 


X is equal to Y 


X* Y 


X is not equal to Y 


Ux 


Dprrpmpnt X h\/ 1 (flnnr 0\ 

L/CW CIMCIIl A uy 1 ^ 1 IUUI \J f 


nx 


Increment X by 1 (modulo register length) 


Erase X 


Erase Flash memory register X 


SetBits[X, Y] 


Set the bits of the Flash memory register X based 
on Y 


Z <- ShiftRight[X, Y] 


Shift register X right one bit position, taking input 
bit from Y and placing the output bit in Z 



4 Pseudocode 

4.1.1 Asynchronous 
The following pseudocode: 

va r = expr e s s i on 
5 means the var signal or output is equal to the evaluation of the expression. 

4.1.2 Synchronous 
The following pseudocode: 

var <r- expression 

means the var register is assigned the result of evaluating the expression during this cycle. 
10 4.1.3 Expression 

Expressions are defined using the nomenclature in Table 231 above. Therefore: 
var = (a = b) 

is interpreted as the var signal is 1 if a is equal to b, and 0 otherwise. 

4.2 Diagrams 

1 5 Black is used to denote data, and red to denote 1-bit control-signal lines. 

4.3 QA Chip Terminology 

This document refers to QA Chips by their function in particular protocols: 
o For authenticated reads, ChipA is the QA Chip being authenticated, and ChipT is the QA 
Chip that is trusted. 

20 o For replacement of keys, ChipP is the QA Chip being programmed with the new key, and 
ChipF is the factory QA Chip that generates the message to program the new key. 
o For upgrades of data in a QA Chip, ChipU is the QA Chip being upgraded, and ChipS is the 

QA Chip that signs the upgrade value. 
Any given physical QA Chip will contain functionality that allows it to operate as an entity in some 
25 number of these protocols. 
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Therefore, wherever the terms ChipA, ChipT, ChipP, ChipF, ChipU and ChipS are used in this 
document, they are referring to logical entities involved in an authentication protocol as defined in 
subsequent sections. 

5 Physical OA Chips are referred to by their location. For example, each ink cartridge may contain a 
OA Chip referred to as an INK_QA, with all INK_QA chips being on the same physical bus. In the 
same way, the QA Chip inside a printer is referred to as PRINTER_QA, and will be on a separate 
bus to the INK_QA chips. 

10 5 Concepts and Terms 

This chapter provides a background to the problem of authenticating consumables. For more in- 
depth introductory texts, see [12], [78], and [56]. 

5.1 Basic terms 

15 A message, denoted by M, is plaintext. The process of transforming M into ciphertext C, where the 
substance of M is hidden, is called encryption. The process of transforming C back into M is called 
decryption. Referring to the encryption function as E, and the decryption function as D, we have the 
following identities: 

E[M] = C 
D[C] = M 

20 

Therefore the following identity is true: 

D[E[M]] = M 

5.2 Symmetric cryptography 

A symmetric encryption algorithm is one where: 
25 o the encryption function E relies on key K 1f 
o the decryption function D relies on key K 2 , 
o K 2 can be derived from K 1f and 
o can be derived from K 2 . 

In most symmetric algorithms, Ki equals K 2 . However, even if does not equal K 2 , given that one 
30 key can be derived from the other, a single key K can suffice for the mathematical definition. Thus: 

E K [M] = C 
D K [C] = M 
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The security of these algorithms rests very much in the key K. Knowledge of K allows anyone to 
encrypt or decrypt. Consequently K must remain a secret for the duration of the value of M. For 
example, M may be a wartime message "My current position is grid position 123-456". Once the 
war is over the value of M is greatly reduced, and if K is made public, the knowledge of the combat 
5 unit's position may be of no relevance whatsoever. Of course if it is politically sensitive for the 

combat unit's position to be known even after the war, K may have to remain secret for a very long 
time. 

An enormous variety of symmetric algorithms exist, from the textbooks of ancient history through to 
1 0 sophisticated modern algorithms. Many of these are insecure, in that modern cryptanalysis 

techniques (see Section 5.7 on page 646) can successfully attack the algorithm to the extent that K 
can be derived. 

The security of the particular symmetric algorithm is a function of two things: the strength of the 
1 5 algorithm and the length of the key [78]. 

The strength of an algorithm is difficult to quantify, relying on its resistance to cryptographic attacks 
(see Section 5.7 on page 646). In addition, the longer that an algorithm has remained in the public 
eye, and yet remained unbroken in the midst of intense scrutiny, the more secure the algorithm is 
20 likely to be. By contrast, a secret algorithm that has not been scrutinized by cryptographic experts is 
unlikely to be secure. 

Even if the algorithm is "perfectly" strong (the only way to break it is to try every key - see Section 
5.7.1 .5 on page 647), eventually the right key will be found. However, the more keys there are, the 
25 more keys have to be tried. If there are N keys, it will take a maximum of N tries. If the key is N bits 
long, it will take a maximum of 2 N tries, with a 50% chance of finding the key after only half the 
attempts (2 N_1 ). The longer N becomes, the longer it will take to find the key, and hence the more 
secure it is. What makes a good key length depends on the value of the secret and the time for 
which the secret must remain secret as well as available computing resources. 

30 

In 1996, an ad hoc group of world-renowned cryptographers and computer scientists released a 
report [9] describing minimal key lengths for symmetric ciphers to provide adequate commercial 
security. They suggest an absolute minimum key length of 90 bits in order to protect data for 20 
years, and stress that increasingly, as cryptosystems succumb to smarter attacks than brute-force 
35 key search, even more bits may be required to account for future surprises in cryptanalysis 
techniques. 
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We will ignore most historical symmetric algorithms on the grounds that they are insecure, 
especially given modern computing technology. Instead, we will discuss the following algorithms: 

DES 
o Blowfish 
5 o RC5 

IDEA 
5.2.1 DES 

DES (Data Encryption Standard) [26] is a US and international standard, where the same key is 
used to encrypt and decrypt. The key length is 56 bits. It has been implemented in hardware and 

1 0 software, although the original design was for hardware only. The original algorithm used in DES 
was patented in 1976 (US patent number 3,962,539) and has since expired. 
During the design of DES, the NSA (National Security Agency) provided secret S-boxes to perform 
the key-dependent nonlinear transformations of the data block. After differential cryptanalysis was 
discovered outside the NSA, it was revealed that the DES S-boxes were specifically designed to be 

1 5 resistant to differential cryptanalysis. 

As described in [95], using 1993 technology, a 56-bit DES key can be recovered by a custom- 
designed $1 million machine performing a brute force attack in only 35 minutes. For $10 million, the 
key can be recovered in only 3.5 minutes. DES is clearly not secure now, and will become less so 
in the future. 

20 A variant of DES, called triple-DES is more secure, but requires 3 keys: K 1( K 2 , and K 3 . The keys 
are used in the following manner: 

The main advantage of triple-DES is that existing DES implementations can be used to give more 
25 security than single key DES. Specifically, triple-DES gives protection of equivalent key length of 
112 bits [78]. Triple-DES does not give the equivalent protection of a 168-bit key (3 x 56) as one 
might naively expect. 

Equipment that performs triple-DES decoding and/or encoding cannot be exported from the United 
States. 
30 5.2.2 Blowfish 

Blowfish is a symmetric block cipher first presented by Schneier in 1994 [76]. It takes a variable 
length key, from 32 bits to 448 bits, is unpatented, and is both license and royalty free. In addition, it 
is much faster than DES. 

The Blowfish algorithm consists of two parts: a key-expansion part and a data-encryption part. Key 
35 expansion converts a key of at most 448 bits into several subkey arrays totaling 4168 bytes. Data 
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encryption occurs via a 16-round Feistel network. All operations are XORs and additions on 32-bit 
words, with four index array lookups per round. 

It should be noted that decryption is the same as encryption except that the subkey arrays are used 
in the reverse order. Complexity of implementation is therefore reduced compared to other 
5 algorithms that do not have such symmetry. 

[77] describes the published attacks which have been mounted on Blowfish, although the algorithm 
remains secure as of February 1998 [79]. The major finding with these attacks has been the 
discovery of certain weak keys. These weak keys can be tested for during key generation. For more 
information, refer to [77] and [79]. 
10 5.2.3 RC5 

Designed by Ron Rivest in 1995, RC5 [74] has a variable block size, key size, and number of 
rounds. Typically, however, it uses a 64-bit block size and a 128-bit key. 
The RC5 algorithm consists of two parts: a key-expansion part and a data-encryption part. Key 
expansion converts a key into 2r+2 subkeys (where r = the number of rounds), each subkey being 
15 w bits. For a 64-bit blocksize with 16 rounds (w=32, r=16), the subkey arrays total 136 bytes. Data 
encryption uses addition mod 2", XOR and bitwise rotation. 

An initial examination by Kaliski and Yin [43] suggested that standard linear and differential 
cryptanalysis appeared impractical for the 64-bit blocksize version of the algorithm. Their differential 
attacks on 9 and 12 round RC5 require 2^ and 2 62 chosen plaintexts respectively, while the linear 
20 attacks on 4, 5, and 6 round RC5 requires 2 37 , 2 47 and 2 57 known plaintexts). These two attacks are 
independent of key size. 

More recently however, Knudsen and Meier [47] described a new type of differential attack on RC5 
that improved the earlier results by a factor of 1 28, showing that RC5 has certain weak keys. 
RC5 is protected by multiple patents owned by RSA Laboratories. A license must be obtained to 
25 use it. 

5.2.4 IDEA 

Developed in 1990 by Lai and Massey [53], the first incarnation of the IDEA cipher was called PES. 
After differential cryptanalysis was discovered by Biham and Shamir in 1991, the algorithm was 
strengthened, with the result being published in 1992 as IDEA [52]. 
30 IDEA uses 128-bit keys to operate on 64-bit plaintext blocks. The same algorithm is used for 

encryption and decryption. It is generally regarded as the most secure block algorithm available 
today [78][78]. 

The biggest drawback of IDEA is the fact that it is patented (US patent number 5,214,703, issued in 
1993), and a license must be obtained from Ascom Tech AG (Bern) to use it. 

35 

5.3 Asymmetric cryptography 

An asymmetric encryption algorithm is one where: 
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o the encryption function E relies on key 
© the decryption function D relies on key K 2 , 

o K 2 cannot be derived from in a reasonable amount of time, and 
o Ki cannot be derived from K 2 in a reasonable amount of time. 
5 Thus: 

E Kl [M] = C 
D K2 [C] = M 

These algorithms are also called public-key because one key can be made public. Thus anyone 
can encrypt a message (using KO but only the person with the corresponding decryption key (K 2 ) 
can decrypt and thus read the message. 
10 In most cases, the following identity also holds: 

E K2 [M] = C 
D Kl [C] = M 

This identity is very important because it implies that anyone with the public key can see M and 
know that it came from the owner of K 2 . No-one else could have generated C because to do so 
1 5 would imply knowledge of K 2 . This gives rise to a different application, unrelated to encryption - 
digital signatures. 

The property of not being able to derive from K 2 and vice versa in a reasonable time is of course 
clouded by the concept of reasonable time. What has been demonstrated time after time, is that a 

20 calculation that was thought to require a long time has been made possible by the introduction of 
faster computers, new algorithms etc. The security of asymmetric algorithms is based on the 
difficulty of one of two problems: factoring large numbers (more specifically large numbers that are 
the product of two large primes), and the difficulty of calculating discrete logarithms in a finite field. 
Factoring large numbers is conjectured to be a hard problem given today's understanding of 

25 mathematics. The problem however, is that factoring is getting easier much faster than anticipated. 
Ron Rivest in 1977 said that factoring a 125-digit number would take 40 quadrillion years [30]. In 
1994 a 129-digit number was factored [3]. According to Schneier, you need a 1024-bit number to 
get the level of security today that you got from a 512-bit number in the 1980s [78]. If the key is to 
last for some years then 1024 bits may not even be enough. Rivest revised his key length estimates 

30 in 1990: he suggests 1628 bits for high security lasting until 2005, and 1884 bits for high security 
lasting until 2015 [69]. Schneier suggests 2048 bits are required in order to protect against 
corporations and governments until 2015 [80]. 
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Public key cryptography was invented in 1976 by Diffie and Hellman [15][15], and independently by 
Merkle [57]. Although Diffie, Hellman and Merkle patented the concepts (US patent numbers 
4,200,770 and 4,218,582), these patents expired in 1997. 

A number of public key cryptographic algorithms exist. Most are impractical to implement, and 
5 many generate a very large C for a given M or require enormous keys. Still others, while secure, 
are far too slow to be practical for several years. Because of this, many public key systems are 
hybrid - a public key mechanism is used to transmit a symmetric session key, and then the session 
key is used for the actual messages. 

All of the algorithms have a problem in terms of key selection. A random number is simply not 
1 0 secure enough. The two large primes p and q must be chosen carefully - there are certain weak 

combinations that can be factored more easily (some of the weak keys can be tested for). But 

nonetheless, key selection is not a simple matter of randomly selecting 1024 bits for example. 

Consequently the key selection process must also be secure. 

Of the practical algorithms in use under public scrutiny, the following are discussed: 
15 o RSA 
DSA 

o EIGamal 

5.3.1 RSA 

The RSA cryptosystem [75], named after Rivest, Shamir, and Adleman, is the most widely used 
20 public key cryptosystem, and is a de facto standard in much of the world [78]. 

The security of RSA depends on the conjectured difficulty of factoring large numbers that are the 

product of two primes (p and q). There are a number of restrictions on the generation of p and q. 

They should both be large, with a similar number of bits, yet not be close to one another (otherwise 

p = q = Vpq). In addition, many authors have suggested that p and q should be strong primes [56]. 
25 The Hellman-Bach patent (US patent number 4,633,036) covers a method for generating strong 

RSA primes p and q such that n = pq and factoring n is believed to be computationally infeasible. 

The RSA algorithm patent was issued in 1983 (US patent number 4,405,829). The patent expires 

on September 20, 2000. 

5.3.2 DSA 

30 DSA (Digital Signature Algorithm) is an algorithm designed as part of the Digital Signature Standard 
(DSS) [29]. As defined, it cannot be used for generalized encryption. In addition, compared to RSA, 
DSA is 10 to 40 times slower for signature verification [40]. DSA explicitly uses the SHA-1 hashing 
algorithm (see Section 5.5.3.3 on page 640). 

DSA key generation relies on finding two primes p and q such that q divides p-1 . According to 
35 Schneier [78], a 1024-bit p value is required for long term DSA security. However the DSA standard 
[29] does not permit values of p larger than 1024 bits (p must also be a multiple of 64 bits). 
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The US Government owns the DSA algorithm and has at least one relevant patent (US patent 

5,231,688 granted in 1993). However, according to NIST [61]: 

"The DSA patent and any foreign counterparts that may issue are available for use 
without any written permission from or any payment of royalties to the U.S. 
5 government. 9 

In a much stronger declaration, NIST states in the same document [61] that DSA does not infringe 

third party's rights: 

"NIST reviewed all of the asserted patents and concluded that none of them would 
be infringed by DSS. Extra protection will be written into the PK1 pilot project that will 
1 0 prevent an organization or individual from suing anyone except the government for 

patent infringement during the course of the project " 
It must however, be noted that the Schnorr authentication algorithm [81] (US patent 4,995,082) 
patent holder claims that DSA infringes his patent. The Schnorr patent is not due to expire until 
2008. 

15 5.3.3 EIGamal 

The EIGamal scheme [22][22] is used for both encryption and digital signatures. The security is 
based on the conjectured difficulty of calculating discrete logarithms in a finite field. 
Key selection involves the selection of a prime p, and two random numbers g and x such that both 
g and x are less than p. Then calculate y-gx mod p. The public key is y, g, and p. The private key 

20 is x. 

EIGamal is unpatented. Although it uses the patented Diffie-Hellman public key algorithm [15][15], 
those patents expired in 1997. EIGamal public key encryption and digital signatures can now be 
safely used without infringing third party patents. 

5.4 Cryptographic challenge-response protocols and zero knowledge proofs 
25 The general principle of a challenge-response protocol is to provide identity authentication. The 
simplest form of challenge-response takes the form of a secret password. A asks B for the secret 
password, and if B responds with the correct password, A declares B authentic. 

There are three main problems with this kind of simplistic protocol. Firstly, once B has responded 
30 with the password, any observer C will know what the password is. Secondly, A must know the 
password in order to verify it. Thirdly, if C impersonates A, then B will give the password to C 
(thinking C was A), thus compromising the password. 

Using a copyright text (such as a haiku) as the password is not sufficient, because we are 
35 assuming that anyone is able to copy the password (for example in a country where intellectual 
property is not respected). 
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The idea of cryptographic challenge-response protocols is that one entity (the claimant) proves its 
identity to another (the verifier) by demonstrating knowledge of a secret known to be associated 
with that entity, without revealing the secret itself Xo the verifier during the protocol [56]. In the 
generalized case of cryptographic challenge-response protocols, with some schemes the verifier 
5 knows the secret, while in others the secret is not even known by the verifier. A good overview of 
these protocols can be found in [25], [78], and [56]. 

Since this documentation specifically concerns Authentication, the actual cryptographic challenge- 
response protocols used for authentication are detailed in the appropriate sections. However the 
1 0 concept of Zero Knowledge Proofs bears mentioning here. 

The Zero Knowledge Proof protocol, first described by Feige, Fiat and Shamir in [24] is extensively 
used in Smart Cards for the purpose of authentication [34][34][34]. The protocol's effectiveness is 
based on the assumption that it is computationally infeasible to compute square roots modulo a 
1 5 large composite integer with unknown factorization. This is provably equivalent to the assumption 
that factoring large integers is difficult. 

It should be noted that there is no need for the claimant to have significant computing power. Smart 
cards implement this kind of authentication using only a few modulo multiplications [34][34]. 

20 Finally, it should be noted that the Zero Knowledge Proof protocol is patented [82] (US patent 
4,748,668, issued May 31, 1988). 

5.5 One-way functions 

A one-way function F operates on an input X, and returns F[X] such that X cannot be determined 
25 from F[X]. When there is no restriction on the format of X, and F[X] contains fewer bits than X, then 
collisions must exist. A collision is defined as two different X input values producing the same F[X] 
value - i.e. X, and X 2 exist such that X, * X 2 yet Fp^] = F[X 2 ]. 

When X contains more bits than F[X], the input must be compressed in some way to create the 
30 output. In many cases, X is broken into blocks of a particular size, and compressed over a number 
of rounds, with the output of one round being the input to the next. The output of the hash function 
is the last output once X has been consumed. A pseudo-collision of the compression function CF is 
defined as two different initial values Vi and V 2 and two inputs X, and X 2 (possibly identical) are 
given such that CF^, X,) = CF(V 2 , X 2 ). Note that the existence of a pseudo-collision does not 
35 mean that it is easy to compute an X 2 for a given X v 
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We are only interested in one-way functions that are fast to compute. In addition, we are only 
interested in deterministic one-way functions that are repeatable in different implementations. 
Consider an example F where F[X] is the time between calls to F. For a given F[X] X cannot be 
determined because X is not even used by F. However the output from F will be different for 
5 different implementations. This kind of F is therefore not of interest. 

In the scope of this document, we are interested in the following forms of one-way functions: 
o Encryption using an unknown key 
o Random number sequences 
10 o Hash Functions 

o Message Authentication Codes 

5.5.1 Encryption using an unknown key 

When a message is encrypted using an unknown key K, the encryption function E is effectively 
1 5 one-way. Without the key, it is computationally infeasible to obtain M from EK[M] without K. An 
encryption function is only one-way for as long as the key remains hidden. 

An encryption algorithm does not create collisions, since E creates EK[M] such that it is possible to 
reconstruct M using function D. Consequently F[X] contains at least as many bits as X (no 
20 information is lost) if the one-way function F is E. 

Symmetric encryption algorithms (see Section 5.2 on page 629) have the advantage over 
asymmetric algorithms (see Section 5.3 on page 632) for producing one-way functions based on 
encryption for the following reasons: 
25 o The key for a given strength encryption algorithm is shorter for a symmetric algorithm than an 
asymmetric algorithm 

o Symmetric algorithms are faster to compute and require less software or silicon 
Note however, that the selection of a good key depends on the encryption algorithm chosen. 
Certain keys are not strong for particular encryption algorithms, so any key needs to be tested for 
30 strength. The more tests that need to be performed for key selection, the less likely the key will 
remain hidden. 

5.5.2 Random number sequences 

Consider a random number sequence Ro, Ri, R„ R*i. We define the one-way function F such 
35 that F[X] returns the X th random number in the random sequence. However we must ensure that 
F[X] is repeatable for a given X on different implementations. The random number sequence 
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therefore cannot be truly random. Instead, it must be pseudo-random, with the generator making 
use of a specific seed. 



There are a large number of issues concerned with defining good random number generators. 
5 Knuth, in [48] describes what makes a generator "good" (including statistical tests), and the general 
problems associated with constructing them. Moreau gives a high level survey of the current state 
of the field in [60]. 

The majority of random number generators produce the P random number from the /-7 th state - the 
1 0 only way to determine the number is to iterate from the 0 th number to the P. If / is large, it may 
not be practical to wait for / iterations. 

However there is a type of random number generator that does allow random access. In [10], Blum, 
Blum and Shub define the ideal generator as follows: "...we would like a pseudo-random sequence 
1 5 generator to quickly produce, from short seeds, long sequences (of bits) that appear in every way to 
be generated by successive flips of a fair coin". They defined the x 2 mod n generator [10], more 
commonly referred to as the BBS generator. They showed that given certain assumptions upon 
which modern cryptography relies, a BBS generator passes extremely stringent statistical tests. 

20 The BBS generator relies on selecting n which is a Blum integer (n = pq where p and q are large 
prime numbers, p*q, p mod 4 = 3, and q mod 4 = 3). The initial state of the generator is given by 
x 0 where x 0 = x 2 mod n, and x is a random integer relatively prime to n. The / h pseudo-random bit is 
the least significant bit of Xj where: 

Xj = x]_ { mod n 

25 

As an extra property, knowledge of p and q allows a direct calculation of the P number in the 
sequence as follows: 

x i — x 0 y mod n where y = 2* mod ((/? - l)(q - 1)) 

Without knowledge of p and g, the generator must iterate (the security of calculation relies on the 
30 conjectured difficulty of factoring large numbers). 

When first defined, the primary problem with the BBS generator was the amount of work required 
for a single output bit. The algorithm was considered too slow for most applications. However the 
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advent of Montgomery reduction arithmetic [58] has given rise to more practical implementations, 
such as [59]. In addition, Vazirani and Vazirani have shown in [93] that depending on the size of n, 
more bits can safely be taken from Xj without compromising the security of the generator. 

5 Assuming we only take 1 bit per x„ N bits (and hence N iterations of the bit generator function) are 
needed in order to generate an N-bit random number. To the outside observer, given a particular 
set of bits, there is no way to determine the next bit other than a 50/50 probability. If the x, p and q 
are hidden, they act as a key, and it is computationally infeasible to take an output bit stream and 
compute x, p, and q. It is also computationally infeasible to determine the value of / used to 
1 0 generate a given set of pseudo-random bits. This last feature makes the generator one-way. 

Different values of / can produce identical bit sequences of a given length (e.g. 32 bits of random 
bits). Even if x, p and q are known, for a given F[/], / can only be derived as a set of possibilities, not 
as a certain value (of course if the domain of / is known, then the set of possibilities is reduced 
further). 

15 

However, there are problems in selecting a good p and g, and a good seed x. In particular, Ritter in 
[68] describes a problem in selecting x. The nature of the problem is that a BBS generator does not 
create a single cycle of known length. Instead, it creates cycles of various lengths, including 
degenerate (zero-length) cycles. Thus a BBS generator cannot be initialized with a random state - it 
20 might be on a short cycle. Specific algorithms exist in section 9 of [10] to determine the length of the 
period for a given seed given certain strenuous conditions for n. 

5.5.3 Hash functions 

Special one-way functions, known as Hash functions, map arbitrary length messages to fixed- 
25 length hash values. Hash functions are referred to as H[M]. Since the input is of arbitrary length, a 
hash function has a compression component in order to produce a fixed length output. Hash 
functions also have an obfuscation component in order to make it difficult to find collisions and to 
determine information about M from H[M]. 

30 Because collisions do exist, most applications require that the hash algorithm is preimage resistant, 
in that for a given Xi it is difficult to find X 2 such that HpCj] = H[X 2 ]. In addition, most applications 
also require the hash algorithm to be collision resistant (i.e. it should be hard to find two messages 
Xt and X 2 such that H[Xi] = H[X 2 ]). However, as described in [20], it is an open problem whether a 
collision-resistant hash function, in the ideal sense, can exist at all. 

35 
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The primary application for hash functions is in the reduction of an input message into a digital 
"fingerprint" before the application of a digital signature algorithm. One problem of collisions with 
digital signatures can be seen in the following example. 

A has a long message Mi that says 7 owe B $10". A signs HfM^ using his private 
5 key. B, being greedy, then searches for a collision message M 2 where H[M 2 ] = HfM^ 

but where M 2 is favorable to B, for example 7 owe B $1million". Clearly it is in A f s 

interest to ensure that it is difficult to find such an M 2 . 

Examples of collision resistant one-way hash functions are SHA-1 [28], MD5 [73] and RIPEMD-160 
1 0 [66], ail derived from MD4 [70][70]. 

5.5.3.7 MD4 

Ron Rivest introduced MD4 [70][70] in 1990. It is only mentioned here because all other one-way 
hash functions are derived in some way from MD4. 

15 

MD4 is now considered completely broken [18][18] in that collisions can be calculated instead of 
searched for. In the example above, B could trivially generate a substitute message M 2 with the 
same hash value as the original message 

20 5.5.3.2 MD5 

Ron Rivest introduced MD5 [73] in 1991 as a more secure MD4. Like MD4, MD5 produces a 128- 
bit hash value. MD5 is not patented [80]. 

Dobbertin describes the status of MD5 after recent attacks [20]. He describes how pseudo- 
25 collisions have been found in MD5, indicating a weakness in the compression function, and more 
recently, collisions have been found. This means that MD5 should not be used for compression in 
digital signature schemes where the existence of collisions may have dire consequences. However 
MD5 can still be used as a one-way function. In addition, the HMAC-MD5 construct (see Section 
5.5.4.1 on page 643) is not affected by these recent attacks. 

30 

5.5.3.3 SHA-1 

SHA-1 [28] is very similar to MD5, but has a 160-bit hash value (MD5 only has 128 bits of hash 
value). SHA-1 was designed and introduced by the NIST and NSA for use in the Digital Signature 
Standard (DSS). The original published description was called SHA [27], but very soon afterwards, 
35 was revised to become SHA-1 [28], supposedly to correct a security flaw in SHA (although the NSA 
has not released the mathematical reasoning behind the change). 
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There are no known cryptographic attacks against SHA-1 [78]. It is also more resistant to brute 
force attacks than MD4 or MD5 simply because of the longer hash result. 

The US Government owns the SHA-1 and DSA algorithms (a digital signature authentication 
5 algorithm defined as part of DSS [29]) and has at least one relevant patent (US patent 5,231 ,688 

granted in 1993). However, according to NIST [61]: 

"The DSA patent and any foreign counterparts that may issue are avaiiable for use 
without any written permission from or any payment of royalties to the U.S. 
government " 

10 

In a much stronger declaration, NIST states in the same document [61] that DSA and SHA-1 do not 

infringe third party's rights: 

"NIST reviewed all of the asserted patents and concluded that none of them would 
be infringed by DSS. Extra protection will be written into the PK1 pilot project that will 
1 5 prevent an organization or individual from suing anyone except the government for 

patent infringement during the course of the project. " 

It must however, be noted that the Schnorr authentication algorithm [81] (US patent number 
4,995,082) patent holder claims that DSA infringes his patent. The Schnorr patent is not due to 
20 expire until 2008. Fortunately this does not affect SHA-1 . 

5.5.3.4 RIPEMD-160 

RIPEMD-160 [66] is a hash function derived from its predecessor RIPEMD [11] (developed for the 
European Community's RIPE project in 1992). As its name suggests, RIPEMD-160 produces a 
25 160-bit hash result. Tuned for software implementations on 32-bit architectures, RIPEMD-160 is 
intended to provide a high level of security for 10 years or more. 

Although there have been no successful attacks on RIPEMD-160, it is comparatively new and has 
not been extensively cryptanalyzed. The original RIPEMD algorithm [11] was specifically designed 
30 to resist known cryptographic attacks on MD4. The recent attacks on MD5 (detailed in [20]) showed 
similar weaknesses in the RIPEMD 128-bit hash function. Although the attacks showed only 
theoretical weaknesses, Dobbertin, Preneel and Bosselaers further strengthened RIPEMD into a 
new algorithm RIPEMD-160. 

35 RIPEMD-160 is in the public domain, and requires no licensing or royalty payments. 

5.5.4 Message authentication codes 
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The problem of message authentication can be summed up as follows: 

How can A be sure that a message supposedly from B is in fact from B? 

Message authentication is different from entity authentication (described in the section on 
5 cryptographic challenge-response protocols). With entity authentication, one entity (the claimant) 
proves its identity to another (the verifier). With message authentication, we are concerned with 
making sure that a given message is from who we think it is from i.e. it has not been tampered with 
en route from the source to its destination. While this section has a brief overview of message 
authentication, a more detailed survey can be found in [88]. 

10 

A one-way hash function is not sufficient protection for a message. Hash functions such as MD5 
rely on generating a hash value that is representative of the original input, and the original input 
cannot be derived from the hash value. A simple attack by E, who is in-between A and B, is to 
intercept the message from B, and substitute his own. Even if A also sends a hash of the original 
1 5 message, E can simply substitute the hash of his new message. Using a one-way hash function 
alone, A has no way of knowing that B's message has been changed. 

One solution to the problem of message authentication is the Message Authentication Code, or 
MAC. 

20 

When B sends message M, it also sends MAC[M] so that the receiver will know that M is actually 
from B. For this to be possible, only B must be able to produce a MAC of M, and in addition, A 
should be able to verify M against MAC[M]. Notice that this is different from encryption of M - MACs 
are useful when M does not have to be secret. 

25 

The simplest method of constructing a MAC from a hash function is to encrypt the hash value with a 
symmetric algorithm: 

1 . Hash the input message H[M] 

2. Encrypt the hash E K [H[M]] 

30 

This is more secure than first encrypting the message and then hashing the encrypted message. 
Any symmetric or asymmetric cryptographic function can be used, with the appropriate advantages 
and disadvantage of each type described in Section 5.2 on page 629 and Section 5.3 on page 632. 

35 However, there are advantages to using a key-dependent one-way hash function instead of 
techniques that use encryption (such as that shown above): 

o Speed, because one-way hash functions in general work much faster than encryption; 
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o Message size, because E K [M] is at least the same size as M, while H[M] is a fixed size 

(usually considerably smaller than M); 
o Hardware/software requirements - keyed one-way hash functions are typically far less 

complex than their encryption-based counterparts; and 
5 o One-way hash function implementations are not considered to be encryption or decryption 

devices and therefore are not subject to US export controls. 
It should be noted that hash functions were never originally designed to contain a key or to support 
message authentication. As a result, some ad hoc methods of using hash functions to perform 
message authentication, including various functions that concatenate messages with secret 
1 0 prefixes, suffixes, or both have been proposed [56][56]. Most of these ad hoc methods have been 
successfully attacked by sophisticated means [42][42][42]. Additional MACs have been suggested 
based on XOR schemes [8] and Toeplitz matrices [49] (including the special case of LFSR-based 
(Linear Feed Shift Register) constructions). 

15 5.5.4.1 HMAC 

The HMAC construction [6][6] in particular is gaining acceptance as a solution for Internet message 
authentication security protocols. The HMAC construction acts as a wrapper, using the underlying 
hash function in a black-box way. Replacement of the hash function is straightforward if desired due 
to security or performance reasons. However, the major advantage of the HMAC construct is that it 
20 can be proven secure provided the underlying hash function has some reasonable cryptographic 
strengths - that is, HMAC's strengths are directly connected to the strength of the hash function [6]. 

Since the HMAC construct is a wrapper, any iterative hash function can be used in an HMAC. 
Examples include HMAC-MD5, HMAC-SHA1, HMAC-RIPEMD1 60 etc. 

25 

Given the following definitions: 

o H = the hash function (e.g. MD5 or SHA-1 ) 

on = number of bits output from H (e.g. 160 for SHA-1 , 128 bits for MD5) 

o M = the data to which the MAC function is to be applied 

30 o k = the secret key shared by the two parties 

© ipad = 0x36 repeated 64 times 
o opad = 0x5C repeated 64 times 

The HMAC algorithm is as follows: 
35 1 . Extend K to 64 bytes by appending 0x00 bytes to the end of K 

2. XOR the 64 byte string created in (1 ) with ipad 

3. append data stream M to the 64 byte string created in (2) 
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4. Apply H to the stream generated in (3) 

5. XOR the 64 byte string created in (1 ) with opad 

6. Append the H result from (4) to the 64 byte string resulting from (5) 

7. Apply H to the output of (6) and output the result 

Thus: 

HMAC[M] = H[(K © opad) | H[(K 0 ipad) | M]] 

The recommended key length is at least n bits, although it should not be longer than 64 bytes (the 
length of the hashing block). A key longer than n bits does not add to the security of the function. 

HMAC optionally allows truncation of the final output e.g. truncation to 128 bits from 160 bits. 

The HMAC designers 1 Request for Comments [51] was issued in 1997, one year after the algorithm 
was first introduced. The designers claimed that the strongest known attack against HMAC is based 
on the frequency of collisions for the hash function H (see Section 14.10 on page 700), and is 
totally impractical for minimally reasonable hash functions: 

As an example, if we consider a hash function iike MD5 where the output length is 
128 bits, the attacker needs to acquire the correct message authentication tags 
computed (with the same secret key K) on about 2 s4 known plaintexts. This would 
require the processing of at least 2 s4 blocks under H, an impossible task in any 
realistic scenario (for a block length of 64 bytes this would take 250,000 years in a 
continuous 1 Gbps link, and without changing the secret key K all this time). This 
attack could become realistic only if serious flaws in the collision behavior of the 
function H are discovered (e.g. Collisions found after 2 30 messages). Such a 
discovery would determine the immediate replacement of function H (the effects of 
such a failure would be far more severe for the traditional uses ofHin the context of 
digital signatures, public key certificates etc). 

Of course, if a 160-bit hash function is used, then 2 s4 should be replaced with 2 80 . 

This should be contrasted with a regular collision attack on cryptographic hash functions where no 
secret key is involved and 2 s4 off-line parallelizable operations suffice to find collisions. 

More recently, HMAC protocols with replay prevention components [62] have been defined in order 
to prevent the capture and replay of any M, HMAC[M] combination within a given time period. 
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Finally, it should be noted that HMAC is in the public domain [50], and incurs no licensing fees. 
There are no known patents infringed by HMAC. 

5.6 Random numbers and time varying messages 
5 The use of a random number generator as a one-way function has already been examined. 

However, random number generator theory is very much intertwined with cryptography, security, 
and authentication. 

There are a large number of issues concerned with defining good random number generators. 
10 Knuth, in [48] describes what makes a generator good (including statistical tests), and the general 
problems associated with constructing them. Moreau gives a high level survey of the current state 
of the field in [60]. 

One of the uses for random numbers is to ensure that messages vary over time. Consider a system 
1 5 where A encrypts commands and sends them to B. If the encryption algorithm produces the same 
output for a given input, an attacker could simply record the messages and play them back to fool 
B. There is no need for the attacker to crack the encryption mechanism other than to know which 
message to play to B (while pretending to be A). Consequently messages often include a random 
number and a time stamp to ensure that the message (and hence its encrypted counterpart) varies 
20 each time. 

Random number generators are also often used to generate keys. Although Klapper has recently 
shown [45] that a family of secure feedback registers for the purposes of building key-streams does 
exist, he does not give any practical construction. It is therefore best to say at the moment that all 
25 generators are insecure for this purpose. For example, the Berlekamp-Massey algorithm [54], is a 
classic attack on an LFSR random number generator. If the LFSR is of length n, then only 2n bits of 
the sequence suffice to determine the LFSR, compromising the key generator. 

If, however, the only role of the random number generator is to make sure that messages vary over 
30 time, the security of the generator and seed is not as important as it is for session key generation. If 
however, the random number seed generator is compromised, and an attacker is able to calculate 
future "random" numbers, it can leave some protocols open to attack. Any new protocol should be 
examined with respect to this situation. 

35 The actual type of random number generator required will depend upon the implementation and the 
purposes for which the generator is used. Generators include Blum, Blum, and Shub [10], stream 
ciphers such as RC4 by Ron Rivest [71], hash functions such as SHA-1 [28] and RIPEMD-160 [66], 
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and traditional generators such LFSRs (Linear Feedback Shift Registers) [48] and their more recent 
counterpart FCSRs (Feedback with Carry Shift Registers) [44], 

5.7 Attacks 

5 This section describes the various types of attacks that can be undertaken to break an 
authentication cryptosystem. The attacks are grouped into physical and logical attacks. 

Logical attacks work on the protocols or algorithms rather than their physical implementation, and 
attempt to do one of three things: 
10 o Bypass the authentication process altogether 

o Obtain the secret key by force or deduction, so that any question can be answered 
o Find enough about the nature of the authenticating questions and answers in order to, 
without the key, give the right answer to each question. 

1 5 Regardless of the algorithms and protocol used by a security chip, the circuitry of the authentication 
part of the chip can come under physical attack. Physical attacks come in four main ways, although 
the form of the attack can vary: 
o Bypassing the security chip altogether 

o Physical examination of the chip while in operation (destructive and non-destructive) 
20 © Physical decomposition of chip 
o Physical alteration of chip 

The attack styles and the forms they take are detailed below. 

25 This section does not suggest solutions to these attacks. It merely describes each attack type. The 
examination is restricted to the context of an authentication chip (as opposed to some other kind of 
system, such as Internet authentication) attached to some System. 

5.7.1 Logical attacks 

30 These attacks are those which do not depend on the physical implementation of the cryptosystem. 
They work against the protocols and the security of the algorithms and random number generators. 

5. 7. 1. 1 Ciphertext only attack 

This is where an attacker has one or more encrypted messages, all encrypted using the same 
35 algorithm. The aim of the attacker is to obtain the plaintext messages from the encrypted 
messages. Ideally, the key can be recovered so that all messages in the future can also be 
recovered. 
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5.7.1.2 Known plaintext attack 

This is where an attacker has both the plaintext and the encrypted form of the plaintext. In the case 
of an authentication chip, a known-plaintext attack is one where the attacker can see the data flow 
5 between the system and the authentication chip. The inputs and outputs are observed (not chosen 
by the attacker), and can be analyzed for weaknesses (such as birthday attacks or by a search for 
differentially interesting input/output pairs). 

A known plaintext attack can be carried out by connecting a logic analyzer to the connection 
1 0 between the system and the authentication chip. 

5.7.1.3 Chosen plaintext attacks 

A chosen plaintext attack describes one where a cryptanalyst has the ability to send any chosen 
message to the cryptosystem, and observe the response. If the cryptanalyst knows the algorithm, 
1 5 there may be a relationship between inputs and outputs that can be exploited by feeding a specific 
output to the input of another function. 

The chosen plaintext attack is much stronger than the known plaintext attack since the attacker can 
choose the messages rather than simply observe the data flow. 

20 

On a system using an embedded authentication chip, it is generally very difficult to prevent chosen 
plaintext attacks since the cryptanalyst can logically pretend he/she is the system, and thus send 
any chosen bit-pattern streams to the authentication chip. 

25 5.7.1.4 Adaptive chosen plaintext attacks 

This type of attack is similar to the chosen plaintext attacks except that the attacker has the added 
ability to modify subsequent chosen plaintexts based upon the results of previous experiments. This 
is certainly the case with any system / authentication chip scenario described for consumables such 
as photocopiers and toner cartridges, especially since both systems and consumables are made 

30 available to the public. 

5.7.1.5 Brute force attack 

A guaranteed way to break any key-based cryptosystem algorithm is simply to try every key. 
Eventually the right one will be found. This is known as a brute force attack. However, the more key 
35 possibilities there are, the more keys must be tried, and hence the longer it takes (on average) to 
find the right one. If there are N keys, it will take a maximum of N tries. If the key is N bits long, it 
will take a maximum of 2 N tries, with a 50% chance of finding the key after only half the attempts 



647 



(2 N1 ). The longer N becomes, the longer it will take to find the key, and hence the more secure the 
key is. Of course, an attack may guess the key on the first try, but this is more unlikely the longer 
the key is. 

5 Consider a key length of 56 bits. In the worst case, all 2 50 tests (7.2 x 10 16 tests) must be made to 
find the key. In 1977, Diffie and Hellman described a specialized machine for cracking DES, 
consisting of one million processors, each capable of running one million tests per second [17]. 
Such a machine would take 20 hours to break any DES code. 

1 0 Consider a key length of 128 bits. In the worst case, all 2 128 tests (3.4 x 10 38 tests) must be made to 
find the key. This would take ten billion years on an array of a trillion processors each running 1 
billion tests per second. 

With a long enough key length, a brute force attack takes too long to be worth the attacker's efforts. 

15 

5.7.1.6 Guessing attack 

This type of attack is where an attacker attempts to simply "guess" the key. As an attack it is 
identical to the brute force attack (see Section 5.7.1 .5 on page 647) where the odds of success 
depend on the length of the key. 

20 

5.7.1.7 Quantum computer attack 

To break an n-bit key, a quantum computer [83] (NMR, Optical, or Caged Atom) containing n qubits 
embedded in an appropriate algorithm must be built. The quantum computer effectively exists in 2 n 
simultaneous coherent states. The trick is to extract the right coherent state without causing any 
25 decoherence. To date this has been achieved with a 2 qubit system (which exists in 4 coherent 

states). It is thought possible to extend this to 6 qubits (with 64 simultaneous coherent states) within 
a few years. 

Unfortunately, every additional qubit halves the relative strength of the signal representing the key. 
30 This rapidly becomes a serious impediment to key retrieval, especially with the long keys used in 
cryptographically secure systems. 

As a result, attacks on a cryptographically secure key (e.g. 160 bits) using a Quantum Computer 
are likely not to be feasible and it is extremely unlikely that quantum computers will have achieved 
35 more than 50 or so qubits within the commercial lifetime of the authentication chips. Even using a 
50 qubit quantum computer, 2 110 tests are required to crack a 160 bit key. 
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5.7.1.8 Purposeful error attack 

With certain algorithms, attackers can gather valuable information from the results of a bad input. 
This can range from the error message text to the time taken for the error to be generated. 

5 A simple example is that of a userid/password scheme. If the error message usually says "Bad 

userid", then when an attacker gets a message saying "Bad password" instead, then they know that 
the userid is correct. If the message always says "Bad userid/password" then much less information 
is given to the attacker. A more complex example is that of the recent published method of cracking 
encryption codes from secure web sites [41], The attack involves sending particular messages to a 
1 0 server and observing the error message responses. The responses give enough information to 
learn the keys - even the lack of a response gives some information. 

An example of algorithmic time can be seen with an algorithm that returns an error as soon as an 
erroneous bit is detected in the input message. Depending on hardware implementation, it may be 
15 a simple method for the attacker to time the response and alter each bit one by one depending on 
the time taken for the error response, and thus obtain the key. Certainly in a chip implementation 
the time taken can be observed with far greater accuracy than over the Internet. 

5.7.1.9 Birthday attack 

20 This attack is named after the famous "birthday paradox" (which is not actually a paradox at all). 
The odds of one person sharing a birthday with another, is 1 in 365 (not counting leap years). 
Therefore there must be 183 people in a room for the odds to be more than 50% that one of them 
shares your birthday. However, there only needs to be 23 people in a room for there to be more 
than a 50% chance that any two share a birthday, as shown in the following relation: 

25 

D , , nPr t 365P23 A CA _ 
Prob = 1 = I — « 0.507 

n 365 23 

Birthday attacks are common attacks against hashing algorithms, especially those algorithms that 
combine hashing with digital signatures. 

30 If a message has been generated and already signed, an attacker must search for a collision 
message that hashes to the same value (analogous to finding one person who shares your 
birthday). However, if the attacker can generate the message, the birthday attack comes into play. 
The attacker searches for two messages that share the same hash value (analogous to any two 
people sharing a birthday), only one message is acceptable to the person signing it, and the other 

35 is beneficial for the attacker. Once the person has signed the original message the attacker simply 
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claims now that the person signed the alternative message - mathematically there is no way to tell 
which message was the original, since they both hash to the same value. 



Assuming a brute force attack is the only way to determine a match, the weakening of an n-bit key 
5 by the birthday attack is 2 n/2 . A key length of 128 bits that is susceptible to the birthday attack has 
an effective length of only 64 bits. 

5.7.1.10 Chaining attack 

These are attacks made against the chaining nature of hash functions. They focus on the 
1 0 compression function of a hash function. The idea is based on the fact that a hash function 

generally takes arbitrary length input and produces a constant length output by processing the input 
n bits at a time. The output from one block is used as the chaining variable set into the next block. 
Rather than finding a collision against an entire input, the idea is that given an input chaining 
variable set, to find a substitute block that will result in the same output chaining variables as the 
1 5 proper message. 

The number of choices for a particular block is based on the length of the block. If the chaining 
variable is c bits, the hashing function behaves like a random mapping, and the block length is b 
bits, the number of such 6-bit blocks is approximately 2? I 2°. The challenge for finding a 
20 substitution block is that such blocks are a sparse subset of all possible blocks. 

For SHA-1 , the number of 51 2 bit blocks is approximately 2 512 /2 160 , or 2 s52 . The chance of finding a 
block by brute force search is about 1 in 2 160 . 

25 5.7.1.11 Substitution with a complete lookup table 

If the number of potential messages sent to the chip is small, then there is no need for a clone 
manufacturer to crack the key. Instead, the clone manufacturer could incorporate a ROM in their 
chip that had a record of all of the responses from a genuine chip to the codes sent by the system. 
The larger the key, and the larger the response, the more space is required for such a lookup table. 

30 

5.7.1.12 Substitution with a sparse lookup table 

If the messages sent to the chip are somehow predictable, rather than effectively random, then the 
clone manufacturer need not provide a complete lookup table. For example: 

35 o |f the message is simply a serial number, the clone manufacturer need simply provide a lookup 
table that contains values for past and predicted future serial numbers. There are unlikely to be 
more than 10 9 of these. 
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o If the test code is simply the date, then the clone manufacturer can produce a lookup table using 
the date as the address. 

o If the test code is a pseudo-random number using either the serial number or the date as a seed, 
then the clone manufacturer just needs to crack the pseudo-random number generator in the 
5 system. This is probably not difficult, as they have access to the object code of the system. The 
clone manufacturer would then produce a content addressable memory (or other sparse array 
lookup) using these codes to access stored authentication codes. 

5.7.1.13 Differential cryptanalysis 
1 0 Differential cryptanalysis describes an attack where pairs of input streams are generated with 
known differences, and the differences in the encoded streams are analyzed. 

Existing differential attacks are heavily dependent on the structure of S boxes, as used in DES and 
other similar algorithms. Although other algorithms such as HMAC-SHA1 have no S boxes, an 
1 5 attacker can undertake a differential-like attack by undertaking statistical analysis of: 
o Minimal-difference inputs, and their corresponding outputs 
o Minimal-difference outputs, and their corresponding inputs 

Most algorithms were strengthened against differential cryptanalysis once the process was 
20 described. This is covered in the specific sections devoted to each cryptographic algorithm. 

However some recent algorithms developed in secret have been broken because the developers 
had not considered certain styles of differential attacks [94] and did not subject their algorithms to 
public scrutiny. 

25 5.7.1.14 Message substitution attacks 

In certain protocols, a man-in-the-middle can substitute part or all of a message. This is where a 
real authentication chip is plugged into a reusable clone chip within the consumable. The clone chip 
intercepts all messages between the system and the authentication chip, and can perform a 
number of substitution attacks. 

30 

Consider a message containing a header followed by content. An attacker may not be able to 
generate a valid header, but may be able to substitute their own content, especially if the valid 
response is something along the lines of "Yes, I received your message". Even if the return 
message is "Yes, I received the following message ...", the attacker may be able to substitute the 
35 original message before sending the acknowledgment back to the original sender. 

Message Authentication Codes were developed to combat message substitution attacks. 
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5. 7.1.15 Reverse engineering the key generator 

If a pseudo-random number generator is used to generate keys, there is the potential for a clone 
manufacture to obtain the generator program or to deduce the random seed used. This was the 
5 way in which the security layer of the Netscape browser program was initially broken [33]. 

5.7.1.16 Bypassing the authentication process 

It may be that there are problems in the authentication protocols that can allow a bypass of the 
authentication process altogether. With these kinds of attacks the key is completely irrelevant, and 
1 0 the attacker has no need to recover it or deduce it. 

Consider an example of a system that authenticates at power-up, but does not authenticate at any 
other time. A reusable consumable with a clone authentication chip may make use of a real 
authentication chip. The clone authentication chip uses the real chip for the authentication call, and 
1 5 then simulates the real authentication chip's state data after that. 

Another example of bypassing authentication is if the system authenticates only after the 
consumable has been used. A clone authentication chip can accomplish a simple authentication 
bypass by simulating a loss of connection after the use of the consumable but before the 
20 authentication protocol has completed (or even started). 

One infamous attack known as the "Kentucky Fried Chip" hack [2] involved replacing a 
microcontroller chip for a satellite TV system. When a subscriber stopped paying the subscription 
fee, the system would send out a "disable" message. However the new micro-controller would 
25 simply detect this message and not pass it on to the consumer's satellite TV system. 

5.7.1.17 Garrote/bribe attack 

If people know the key, there is the possibility that they could tell someone else. The telling may be 
due to coercion (bribe, garrote etc.), revenge (e.g. a disgruntled employee), or simply for principle. 
30 These attacks are usually cheaper and easier than other efforts at deducing the key. As an 

example, a number of people claiming to be involved with the development of the (now defunct) 
Divx standard for DVD claimed (before the standard was rejected by consumers) that they would 
like to help develop Divx specific cracking devices - out of principle. 

35 5.7.2 Physical attacks 

The following attacks assume implementation of an authentication mechanism in a silicon chip that 
the attacker has physical access to. The first attack, Reading ROM, describes an attack when keys 
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are stored in ROM, while the remaining attacks assume that a secret key is stored in Flash 
memory. 

5. 7. 2. 1 Reading ROM 

5 If a key is stored in ROM it can be read directly. A ROM can thus be safely used to hold a public 
key (for use in asymmetric cryptography), but not to hold a private key. In symmetric cryptography, 
a ROM is completely insecure. Using a copyright text (such as a haiku) as the key is not sufficient, 
because we are assuming that the cloning of the chip is occurring in a country where intellectual 
property is not respected. 

10 

5. 7. 2. 2 Reverse engineering of chip 

Reverse engineering of the chip is where an attacker opens the chip and analyzes the circuitry. 
Once the circuitry has been analyzed the inner workings of the chip's algorithm can be recovered. 
Lucent Technologies have developed an active method [4] known as TOBIC (Two photon OBIC, 
1 5 where OBIC stands for Optical Beam Induced Current), to image circuits. Developed primarily for 
static RAM analysis, the process involves removing any back materials, polishing the back surface 
to a mirror finish, and then focusing light on the surface. The excitation wavelength is specifically 
chosen not to induce a current in the IC. 

20 A Kerckhoffs in the nineteenth century made a fundamental assumption about cryptanalysis: if the 
algorithm's inner workings are the sole secret of the scheme, the scheme is as good as broken [39], 
He stipulated that the secrecy must reside entirely in the key. As a result, the best way to protect 
against reverse engineering of the chip is to make the inner workings irrelevant. 

25 5.7.2.3 Usurping the authentication process 

It must be assumed that any clone manufacturer has access to both the system and consumable 
designs. 

If the same channel is used for communication between the system and a trusted system 
30 authentication chip, and a non-trusted consumable authentication chip, it may be possible for the 
non-trusted chip to interrogate a trusted authentication chip in order to obtain the "correct answer". 
If this is so, a clone manufacturer would not have to determine the key. They would only have to 
trick the system into using the responses from the system authentication chip. 

35 The alternative method of usurping the authentication process follows the same method as the 
logical attack described in Section 5.7.1 .16 on page 652, involving simulated loss of contact with 
the system whenever authentication processes take place, simulating power-down etc. 
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5. 7. 2. 4 Modification of system 

This kind of attack is where the system itself is modified to accept clone consumables. The attack 
may be a change of system ROM, a rewiring of the consumable, or, taken to the extreme case, a 
5 com pletely done system . 

Note that this kind of attack requires each individual system to be modified, and would most likely 
require the owner's consent. There would usually have to be a clear advantage for the consumer to 
undertake such a modification, since it would typically void warranty and would most likely be 
1 0 costly. An example of such a modification with a clear advantage to the consumer is a software 

patch to change fixed-region DVD players into region-free DVD players (although it should be noted 
that this is not to use clone consumables, but rather originals from the same companies simply 
targeted for sale in other countries). 

15 5.7.2.5 Direct viewing of chip operation by conventional probing 

If chip operation could be directly viewed using an STM (Scanning Tunnelling Microscope) or an 
electron beam, the keys could be recorded as they are read from the internal non-volatile memory 
and loaded into work registers. 

20 These forms of conventional probing require direct access to the top or front sides of the IC while it 
is powered. 

5. 7. 2. 6 Direct viewing of the non-volatile memory 

If the chip were sliced so that the floating gates of the Flash memory were exposed, without 
25 discharging them, then the key could probably be viewed directly using an STM or SKM (Scanning 
Kelvin Microscope). 

However, slicing the chip to this level without discharging the gates is probably impossible. Using 
wet etching, plasma etching, ion milling (focused ion beam etching), or chemical mechanical 
30 polishing will almost certainly discharge the small charges present on the floating gates. 

5. 7.2. 7 Viewing the light bursts caused by state changes 

Whenever a gate changes state, a small amount of infrared energy is emitted. Since silicon is 
transparent to infrared, these changes can be observed by looking at the circuitry from the 
35 underside of a chip. While the emission process is weak, it is bright enough to be detected by highly 
sensitive equipment developed for use in astronomy. The technique [92], developed by IBM, is 
called PICA (Picosecond Imaging Circuit Analyzer). If the state of a register is known at time t, then 
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watching that register change over time will reveal the exact value at time f+n, and if the data is part 
of the key, then that part is compromised. 

5. 7. 2. 8 Viewing the keys using an SEPM 

5 A non-invasive testing device, known as a Scanning Electric Potential Microscope (SEPM), allows 
the direct viewing of charges within a chip [37]. The SEPM has a tungsten probe that is placed a 
few micrometers above the chip, with the probe and circuit forming a capacitor. Any AC signal 
flowing beneath the probe causes displacement current to flow through this capacitor. Since the 
value of the current change depends on the amplitude and phase of the AC signal, the signal can 
10 be imaged. If the signal is part of the key, then that part is compromised. 

5. 7. 2. 9 Monitoring EMI 

Whenever electronic circuitry operates, faint electromagnetic signals are given off. Relatively 
inexpensive equipment can monitor these signals and could give enough information to allow an 
1 5 attacker to deduce the keys. 

5. 7.2.10 Viewing / dd fluctuations 

Even if keys cannot be viewed, there is a fluctuation in current whenever registers change state. If 
there is a high enough signal to noise ratio, an attacker can monitor the difference in l dd that may 
20 occur when programming over either a high or a low bit. The change in l dd can reveal information 
about the key. Attacks such as these have already been used to break smart cards [46]. 

5. 7.2.11 Differential Fault Analysis 

This attack assumes introduction of a bit error by ionization, microwave radiation, or environmental 
25 stress. In most cases such an error is more likely to adversely affect the chip (e.g. cause the 

program code to crash) rather than cause beneficial changes which would reveal the key. Targeted 
faults such as ROM overwrite, gate destruction etc. are far more likely to produce useful results. 

5.7.2.12 Clock glitch attacks 

30 Chips are typically designed to properly operate within a certain clock speed range. Some attackers 
attempt to introduce faults in logic by running the chip at extremely high clock speeds or introduce a 
clock glitch at a particular time for a particular duration [1]. The idea is to create race conditions 
where the circuitry does not function properly. An example could be an AND gate that (because of 
race conditions) gates through Input, all the time instead of the AND of Inputi and !nput 2 . 
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If an attacker knows the internal structure of the chip, they can attempt to introduce race conditions 
at the correct moment in the algorithm execution, thereby revealing information about the key (or in 
the worst case, the key itself). 



5 5.7.2.13 Power supply attacks 

Instead of creating a glitch in the clock signal, attackers can also produce glitches in the power 
supply where the power Is increased or decreased to be outside the working operating voltage 
range. The net effect is the same as a clock glitch - introduction of error in the execution of a 
particular instruction. The idea is to stop the CPU from XORing the key, or from shifting the data 
1 0 one bit-position etc. Specific instructions are targeted so that information about the key is revealed. 

5.7.2.14 Overwriting ROM 

Single bits in a ROM can be overwritten using a laser cutter microscope [1], to either 1 or 0 
depending on the sense of the logic. If the ROM contains instructions, it may be a simple matter for 
15 an attacker to change a conditional jump to a non-conditional jump, or perhaps change the 

destination of a register transfer. If the target instruction is chosen carefully, it may result in the key 
being revealed. 

5.7.2.15 Modifying EEPROM/Flash 
20 These attacks fall into two categories: 

o those similar to the ROM attacks except that the laser cutter microscope technique can be 
used to both set and reset individual bits. This gives much greater scope in terms of 
modification of algorithms. 

o Electron beam programming of floating gates. As described in [89] and [32], a focused 
25 electron beam can change a gate by depositing electrons onto it. Damage to the rest of the 

circuit can be avoided, as described in [31]. 

5.7.2.16 Gate destruction 

Anderson and Kuhn described the rump session of the 1997 workshop on Fast Software Encryption 
30 [1], where Biham and Shamir presented an attack on DES. The attack was to use a laser cutter to 
destroy an individual gate in the hardware implementation of a known block cipher (DES). The net 
effect of the attack was to force a particular bit of a register to be "stuck". Biham and Shamir 
described the effect of forcing a particular register to be affected in this way - the least significant bit 
of the output from the round function is set to 0. Comparing the 6 least significant bits of the left half 
35 and the right half can recover several bits of the key. Damaging a number of chips in this way can 
reveal enough information about the key to make complete key recovery easy. 
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An encryption chip modified in this way will have the property that encryption and decryption will no 
longer be inverses. 

5. 7.2.17 Overwrite attacks 

5 Instead of trying to read the Flash memory, an attacker may simply set a single bit by use of a laser 
cutter microscope. Although the attacker doesn't know the previous value, they know the new 
value. If the chip still works, the bit's original state must be the same as the new state. If the chip 
doesn't work any longer, the bit's original state must be the logical NOT of the current state. An 
attacker can perform this attack on each bit of the key and obtain the n-bit key using at most n chips 
10 (if the new bit matched the old bit, a new chip is not required for determining the next bit). 

5. 7.2.18 Test circuitry attack 

Most chips contain test circuitry specifically designed to check for manufacturing defects. This 
includes BIST (Built In Self Test) and scan paths. Quite often the scan paths and test circuitry 
1 5 includes access and readout mechanisms for all the embedded latches. In some cases the test 
circuitry could potentially be used to give information about the contents of particular registers. 

Test circuitry is often disabled once the chip has passed ail manufacturing tests, in some cases by 
blowing a specific connection within the chip. A determined attacker, however, can reconnect the 
20 test circuitry and hence enable it. 

5. 7.2.19 Memory remnants 

Values remain in RAM long after the power has been removed [35], although they do not remain 
long enough to be considered non-volatile. An attacker can remove power once sensitive 
25 information has been moved into RAM (for example working registers), and then attempt to read 
the value from RAM. This attack is most useful against security systems that have regular RAM 
chips. A classic example is cited by [1], where a security system was designed with an automatic 
power-shut-off that is triggered when the computer case is opened. The attacker was able to simply 
open the case, remove the RAM chips, and retrieve the key because the values persisted. 

30 

5.7.2.20 Chip theft attack 

If there are a number of stages in the lifetime of an authentication chip, each of these stages must 
be examined in terms of ramifications for security should chips be stolen. For example, if 
information is programmed into the chip in stages, theft of a chip between stages may allow an 
35 attacker to have access to key information or reduced efforts for attack. Similarly, if a chip is stolen 
directly after manufacture but before programming, does it give an attacker any logical or physical 
advantage? 
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5. 7.2.21 Trojan horse attack 

At some stage the authentication chips must be programmed with a secret key. Suppose an 
attacker builds a clone authentication chip and adds it to the pile of chips to be programmed. The 
attacker has especially built the clone chip so that it looks and behaves just like a real 
5 authentication chip, but will give the key out to the attacker when a special attacker-known 
command is issued to the chip. Of course the attacker must have access to the chip after the 
programming has taken place, as well as physical access to add the Trojan horse authentication 
chip to the genuine chips. 

10 6 Requirements 

Existing solutions to the problem of authenticating consumables have typically relied on patents 
covering physical packaging. However this does not stop home refill operations or clone 
manufacture in countries with weak industrial property protection. Consequently a much higher 
level of protection is required. 

15 

The authentication mechanism is therefore built into an authentication chip that is embedded in the 
consumable and allows a system to authenticate that consumable securely and easily. Limiting 
ourselves to the system authenticating consumables (we don't consider the consumable 
authenticating the system), two levels of protection can be considered: 

20 

Presence Only Authentication: 

This is where only the presence of an authentication chip is tested. The authentication 
chip can be removed and used in other consumables as long as be used indefinitely. 

25 Consumable Lifetime Authentication: 

This is where not only is the presence of the authentication chip tested for, but also the 
authentication chip must only last the lifetime of the consumable. For the chip to be re- 
used it must be completely erased and reprogrammed. 

30 The two levels of protection address different requirements. We are primarily concerned with 
Consumable Lifetime authentication in order to prevent cloned versions of high volume 
consumables. In this case, each chip should hold secure state information about the consumable 
being authenticated. It should be noted that a Consumable Lifetime authentication chip could be 
used in any situation requiring a Presence Only authentication chip. 

35 

Requirements for authentication, data storage integrity and manufacture are considered separately. 
The following sections summarize requirements of each. 
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6.1 Authentication 

The authentication requirements for both Presence Only and Consumable Lifetime authentication 
are restricted to the case of a system authenticating a consumable. We do not consider bi- 
5 directional authentication where the consumable also authenticates the system. For example, it is 
not necessary for a valid toner cartridge to ensure it is being used in a valid photocopier. 

For Presence Only authentication, we must be assured that an authentication chip is physically 
present. For Consumable Lifetime authentication we also need to be assured that state data 
1 0 actually came from the authentication chip, and that it has not been altered en route. These issues 
cannot be separated - data that has been altered has a new source, and if the source cannot be 
determined, the question of alteration cannot be settled. 

It is not enough to provide an authentication method that is secret, relying on a home-brew security 
1 5 method that has not been scrutinized by security experts. The primary requirement therefore is to 
provide authentication by means that have withstood the scrutiny of experts. 

The authentication scheme used by the authentication chip should be resistant to defeat by logical 
means. Logical types of attack are extensive, and attempt to do one of three things: 
20 © Bypass the authentication process altogether 

o Obtain the secret key by force or deduction, so that any question can be answered 
o Find enough about the nature of the authenticating questions and answers in order to, 
without the key, give the right answer to each question. 

25 The logical attack styles and the forms they take are detailed in Section 5.7.1 on page 646. 

The algorithm should have a flat keyspace, allowing any random bit string of the required length to 
be a possible key. There should be no weak keys. 

30 6.2 Data storage integrity 

Although authentication protocols take care of ensuring data integrity in communicated messages, 
data storage integrity is also required. Two kinds of data must be stored within the authentication 
chip: 

o Authentication data, such as secret keys 
35 © Consumable state data, such as serial numbers, and media remaining etc. 
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The access requirements of these two data types differ greatly. The authentication chip therefore 
requires a storage/access control mechanism that allows for the integrity requirements of each 
type. 

5 6.2.1 Authentication data 

Authentication data must remain confidential. It needs to be stored in the chip during a 
manufacturing/programming stage of the chip's life, but from then on must not be permitted to leave 
the chip. It must be resistant to being read from non-volatile memory. The authentication scheme is 
responsible for ensuring the key cannot be obtained by deduction, and the manufacturing process 
10 is responsible for ensuring that the key cannot be obtained by physical means. 

The size of the authentication data memory area must be large enough to hold the necessary keys 
and secret information as mandated by the authentication protocols. 

1 5 6.2.2 Consumable state data 

Consumable state data can be divided into the following types. Depending on the application, there 

will be different numbers of each of these types of data items. 

o Read Only 

o Read Write 
20 o Decrement Only 

Read Only data needs to be stored in the chip during a manufacturing/programming stage of the 
chip's life, but from then on should not be allowed to change. Examples of Read Only data 
items are consumable batch numbers and serial numbers. 

25 ReadWrite data is changeable state information, for example, the last time the particular 

consumable was used. ReadWrite data items can be read and written an unlimited number of 
times during the lifetime of the consumable. They can be used to store any state information 
about the consumable. The only requirement for this data is that it needs to be kept in non- 
volatile memory. Since an attacker can obtain access to a system (which can write to 

30 ReadWrite data), any attacker can potentially change data fields of this type. This data type 

should not be used for secret information, and must be considered insecure. 
Decrement Only data is used to count down the availability of consumable resources. A 

photocopier's toner cartridge, for example, may store the amount of toner remaining as a 
Decrement Only data item. An ink cartridge for a color printer may store the amount of each 

35 ink color as a Decrement Only data item, requiring 3 (one for each of Cyan, Magenta, and 

Yellow), or even as many as 5 or 6 Decrement Only data items. The requirement for this kind 
of data item is that once programmed with an initial value at the manufacturing/programming 
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stage, it can only reduce in value. Once it reaches the minimum value, it cannot decrement 
any further. The Decrement Only data item is only required by Consumable Lifetime 
authentication. 

5 Note that the size of the consumable state data storage required is only for that information 
required to be authenticated. Information which would be of no use to an attacker, such as ink 
color-curve characteristics or ink viscosity do not have to be stored in the secure state data memory 
area of the authentication chip. 

10 6.3 Manufacture 

The authentication chip must have a low manufacturing cost in order to be included as the 
authentication mechanism for low cost consumables. 

The authentication chip should use a standard manufacturing process, such as Flash. This is 
1 5 necessary to: 

o Allow a great range of manufacturing location options 
o Use well-defined and well-behaved technology 
o Reduce cost 

20 Regardless of the authentication scheme used, the circuitry of the authentication part of the chip 

must be resistant to physical attack. Physical attack comes in four main ways, although the form of 
the attack can vary: 

o Bypassing the authentication chip altogether 

o Physical examination of chip while in operation (destructive and non-destructive) 
25 © Physical decomposition of chip 
o Physical alteration of chip 

The physical attack styles and the forms they take are detailed in Section 5.7.2 on page 652. 
Ideally, the chip should be exportable from the USA, so it should not be possible to use an 
30 authentication chip as a secure encryption device. This is low priority requirement since there are 
many companies in other countries able to manufacture the authentication chips. In any case, the 
export restrictions from the USA may change. 

Authentication 
35 7 Introduction 

Existing solutions to the problem of authenticating consumables have typically relied on physical 
patents on packaging. However this does not stop home refill operations or clone manufacture in 
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countries with weak industrial property protection. Consequently a much higher level of protection is 
required. 

It is not enough to provide an authentication method that is secret, relying on a home-brew security 
5 method that has not been scrutinized by security experts. Security systems such as Netscape's 
original proprietary system and the GSM Fraud Prevention Network used by cellular phones are 
examples where design secrecy caused the vulnerability of the security [33][33]. Both security 
systems were broken by conventional means that would have been detected if the companies had 
followed an open design process. The solution is to provide authentication by means that have 
1 0 withstood the scrutiny of experts. 

In this section, we examine a number of protocols that can be used for consumables authentication. 
We only use security methods that are publicly described, using known behaviors in this new way. 
Readers should be familiar with the concepts and terms described in Section 5 on page 629. We 
1 5 avoid the Zero Knowledge Proof protocol since it is patented. 

For ail protocols, the security of the scheme relies on a secret key, not a secret algorithm. In the 
nineteenth century, A Kerckhoffs made a fundamental assumption about cryptanalysis: if the 
algorithm's inner workings are the sole secret of the scheme, the scheme is as good as broken [39]. 
20 He stipulated that the secrecy must reside entirely in the key. As a result, the best way to protect 
against reverse engineering of any authentication chip is to make the algorithmic inner workings 
irrelevant (the algorithm of the inner workings must still be must be valid, but not the actual secret). 

The QA Chip is a programmable device, and can therefore be setup with an application-specific 
25 program together with an application-specific set of protocols. This section describes the following 
sets of protocols: 

o single key single memory vector 
o multiple key single memory vector 
o multiple key multiple memory vector 

30 

These protocols refer to the number of valid keys that an QA Chip knows about, and the size of 
data required to be stored in the chip. 

From these protocols it is straightforward to construct protocol sets for the single key multiple 
35 memory vector case (of course the multiple memory vector can be considered to be . and multiple 
key single memory vector. Other protocol sets can also be defined as necessary. Of course multiple 
memory vector can be conveniently 
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All the protocols rely on a time-variant challenge (i.e. the challenge is different each time), where 
the response depends on the challenge and the secret. The challenge involves a random number 
so that any observer will not be able to gather useful information about a subsequent identification. 

5 

8 Single Key Single Memory Vector 

8. 1 Protocol background 

This protocol set is provided for two reasons: 

o the other protocol sets defined in this document are simply extensions of this one; and 
10 o it is useful in its own right 

The single key protocol set is useful for applications where only a single key is required. Note that 
there can be many consumables and systems, but there is only a single key that connects them all. 
Examples include: 

15 o car and keys. A car and the car-key share a single key. There can be multiple sets of car- 
keys, each effectively cut to the same key. A company could have a set of cars, each with 
the same key. Any of the car-keys could then be used to drive any of the cars, 
o printer and ink cartridge. All printers of a certain model use the same ink cartridge, with 
printer and cartridge sharing only a single key. Note that to introduce a new printer model 

20 that accepts the old ink cartridge the new model would need the same key as the old model. 

See the multiple-key protocols for alternative solutions to this problem. 



8.2 Requirements of protocol 
Each QA Chip contains the following values: 
25 K The secret key for calculating F K [X], K must not be stored directly in the QA Chip. 

Instead, each chip needs to store a random number R K (different for each chip), 
K©Rk, and -.K0R K . The stored K0Rk can be XORed with R K to obtain the real K. 
Although -hK®Rk must be stored to protect against differential attacks, it is not 
used. 

30 R Current random number used to ensure time varying messages. Each chip 

instance must be seeded with a different initial value. Changes for each signature 
generation. 
M Memory vector of QA Chip. 

P 2 element array of access permissions for each part of M. Entry 0 holds access 

35 permissions for non-authenticated writes to M (no key required). Entry 1 holds 

access permissions for authenticated writes to M (key required). Permission 
choices for each part of M are Read Only, Read/Write, and Decrement Only. 
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C 3 constants used for generating signatures. C 1f C 2t and C 3 are constants that pad 

out a submessage to a hashing boundary, and all 3 must be different. 
Each QA Chip contains the following private function: 

S K [X] Internal function only. Returns S K [X], the result of applying a digital signature 

function S to X based upon key K. The digital signature must be long enough to 
counter the chances of someone generating a random signature. The length 
depends on the signature scheme chosen, although the scheme chosen for the QA 
Chip is HMAC-SHA1 (see Section 13 on page 691), and therefore the length of the 
signature is 160 bits. 

Additional functions are required in certain QA Chips, but these are described as required. 



8.3 Reads of M 

In this case, we have a trusted chip (ChipT) connected to a System. The System wants to 
1 5 authenticate an object that contains a non-trusted chip {ChipA). In effect, the System wants to know 
that it can securely read a memory vector (M) from ChipA: to be sure that ChipA is valid and that M 
has not been altered. 

The protocol requires the following publicly available function in ChipA: 

Read[X] Advances R, and returns R, M, S K [X|R|Ci|M]. The time taken to calculate the 
20 signature must not be based on the contents of X, R f M, or K. 

The protocol requires the following publicly available functions in ChipT: 
Random^ Returns R (does not advance R). 

Test[X, Y, Z] Advances R and returns 1 if S^RPC^Y] = Z. Otherwise returns 0. The time 
25 taken to calculate and compare signatures must be independent of data content. 

To authenticate ChipA and read ChipA's memory M: 

a. System calls ChipT's Random function; 

b. ChipT returns R T to System; 

30 c. System calls ChipA's Read function, passing in the result from b; 

d. ChipA updates R A , then calculates and returns R A , M A> SKlR-rlRAlCilM/J; 

e. System calls ChipT's Test function, passing in R A , M A , SkIRt-IRa^IM/v]; 

f. System checks response from ChipT. If the response is 1 , then ChipA is considered authentic. If 
0, ChipA is considered invalid. 
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The data flow for read authentication is shown in Figure 334. 
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The protocol allows System to simply pass data from one chip to another, with no special 
processing. The protection relies on ChipT being trusted, even though System does not know K. 

When ChipT is physically separate from System (eg is chip on a board connected to System) 
5 System must also occassionally (based on system clock for example) call ChipT's Test function 
with bad data, expecting a 0 response. This is to prevent someone from inserting a fake ChipT into 
the system that always returns 1 for the Test function. 

8.4 Writes 

10 In this case, the System wants to update M in some chip referred to as ChipU. This can be non- 
authenticated (for example, anyone is allowed to count down the amount of consumable 
remaining), or authenticated (for example, replenishing the amount of consumable remaining). 

8.4.1 Non-authenticated writes 

1 5 This is the most frequent type of write, and takes place between the System / consumable during 
normal everyday operation. In this kind of write, System wants to change M in a way that doesn't 
require special authorization. For example, the System could be decrementing the amount of 
consumable remaining. Although System does not need to know K or even have access to a 
trusted chip, System must follow a non-authenticated write by an authenticated read if it needs to 

20 know that the write was successful. 

The protocol requires the following publicly available function: 

WritefX] Writes X over those parts of M subject to P 0 and the existing value for M. 

25 To authenticate a write of Mnew to ChipA's memory M: 

a. System calls ChipU's Write function, passing in Mnew,' 

b. The authentication procedure for a Read is carried out (see Section 8.3 on page 664); 

c. If ChipU is authentic and M new = M returned in b, the write succeeded. If not, it failed. 

30 8.4.2 Authenticated writes 

In this kind of write, System wants to change Chip ITs M in an authorized way, without being 
subject to the permissions that apply during normal operation (P 0 ). For example, the consumable 
may be at a refilling station and the normally Decrement Only section of M should be updated to 
include the new valid consumable. In this case, the chip whose M is being updated must 

35 authenticate the writes being generated by the external System and in addition, apply permissions 
Pi to ensure that only the correct parts of M are updated. 
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In this transaction protocol, the System's chip is referred to as ChipS, and the chip being updated is 

referred to as ChipU. Each chip distrusts the other. 

The protocol requires the following publicly available functions in ChipU: 

Read[X] Advances R, and returns R, M, S K [X|R|Ci|M]. The time taken to calculate the 
5 signature must be identical for all inputs. 

WriteA[X, Y, 2]Returns 1 , advances R, and replaces M by Y subject to P, only if S K [R|X|d|Y] = 
Z. Otherwise returns 0. The time taken to calculate and compare 
signatures must be independent of data content. This function is identical 
to ChipT's Test function except that it additionally writes Y over those 
1 0 parts of M subject to P<\ when the signature matches. 



Authenticated writes require that the System has access to a ChipS that is capable of generating 
appropriate signatures. ChipS requires the following variables and function: 

CountRemaining Part of M that contains the number of signatures that ChipS is allowed to 

1 5 generate. Decrements with each successful call to SignM and SignP. 

Permissions in ChipS's P 0 for this part of M needs to be Readonly once 
ChipS has been setup. Therefore CountRemaining can only be updated 
by another ChipS that will perform updates to that part of M (assuming 
ChipS's Pi allows that part of M to be updated). 

20 Q Part of M that contains the write permissions for updating ChipU's M. By 

adding Q to ChipS we allow different ChipSs that can update different 
parts of My. Permissions in ChipS's P 0 for this part of M needs to be 
Readonly once ChipS has been setup. Therefore Q can only be updated 
by another ChipS that will perform updates to that part of M. 

25 SignMtV,W,X,Y,Z] Advances R, decrements CountRemaining and returns R, Zqx (Z applied 

to X with permissions Q), followed by SkIWIRIC^Zqx] only if SkMWIC^X] 
= Y and CountRemaining > 0. Otherwise returns all 0s. The time taken to 
calculate and compare signatures must be independent of data content. 



30 To update ChipU's M vector: 

a. System calls ChipU's Read function, passing in 0 as the input parameter; 

b. ChipU produces R Uf M y , SKlOIRulCilMy] and returns these to System; 

c. System calls ChipS's SignM function, passing in 0 (as used in a), Ry, Mu, SkIOIRuICtIMu], and 
M D (the desired vector to be written to ChipU); 

35 d. ChipS produces R s , M QD (processed by running M D against My using Q) and S K [Ru|Rs|Ci|M QD ] if 
the inputs were valid, and 0 for all outputs if the inputs were not valid. 
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e. If values returned in d are non zero, then ChipU is considered authentic. System can then call 
ChipU's WriteA function with these values. 

f. ChipU should return a 1 to indicate success. A 0 should only be returned if the data generated 
by ChipS is incorrect (e.g. a transmission error). 

5 The data flow for authenticated writes is shown in Figure 335. 

Note that Q in ChipS is part of ChipS's M. This allows a user to set up Chips with a permission set 
for upgrades. This should be done to ChipS and that part of M designated by P 0 set to Readonly 
before ChipS is programmed with K u . If Ks is programmed with K u first, there is a risk of someone 
1 0 obtaining a half-setup ChipS and changing all of M v instead of only the sections specified by Q. 

The same is true of CountRemaining. The CountRemaining value needs to be setup (including 
making it Readonly in P 0 ) before ChipS is programmed with K u . ChipS is therefore programmed to 
only perform a limited number of SignM operations (thereby limiting compromise exposure if a 
1 5 ChipS is stolen). Thus ChipS would itself need to be upgraded with a new CountRemaining every 
so often. 

8.4.3 Updating permissions for future writes 

In order to reduce exposure to accidental and malicious attacks on P and certain parts of M, only 
20 authorized users are allowed to update P. Writes to P are the same as authorized writes to M, 

except that they update P n instead of M. Initially (at manufacture), P is set to be Read/Write for all 
parts of M. As different processes fill up different parts of M, they can be sealed against future 
change by updating the permissions. Updating a chip's P 0 changes permissions for unauthorized 
writes, and updating Pi changes permissions for authorized writes. 

25 

P n is only allowed to change to be a more restrictive form of itself. For example, initially all parts of 
M have permissions of Read/Write. A permission of Read/Write can be updated to Decrement Only 
or Read Only. A permission of Decrement Only can be updated to become Read Only. A Read 
Only permission cannot be further restricted. 

30 

In this transaction protocol, the System's chip is referred to as ChipS, and the chip being updated is 
referred to as ChipU. Each chip distrusts the other. 

The protocol requires the following publicly available functions in ChipU: 
35 Random Q Returns R (does not advance R). 

SetPermission[n,X,Y,Z] Advances R, and updates P n according to Y and returns 1 followed by 
the resultant P n only if S K [R|X|Y|C2] = Z. Otherwise returns 0. P n can only 
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become more restricted. Passing in 0 for any permission leaves it unchanged 
(passing in Y=0 returns the current P n ). 



Authenticated writes of permissions require that the System has access to a ChipS that is capable 
5 of generating appropriate signatures. ChipS requires the following variables and function: 

CountRemaining Part of M that contains the number of signatures that ChipS is allowed to 
generate. Decrements with each successful call to SignM and SignP. 
Permissions in ChipS's P 0 for this part of M needs to be Readonly once 
ChipS has been setup. Therefore CountRemaining can only be updated by 
1 0 another ChipS that will perform updates to that part of M (assuming ChipS's 

P A allows that part of M to be updated). 
SignP[X,Y] Advances R, decrements CountRemaining and returns R and S K [X|R|Y|C 2 ] 
only if CountRemaining > 0. Otherwise returns all 0s. The time taken to 
calculate and compare signatures must be independent of data content. 

15 

To update ChipU's P n : 

a. System calls ChipU's Random function; 

b. ChipU returns Ru to System; 

c. System calls ChipS's SignP function, passing in R u and P D (the desired P to be written to 
20 ChipU); 

d. ChipS produces Rs and S k [Ru|Rs|Pd|C2] if it is still permitted to produce signatures. 

e. If values returned in d are non zero, then System can then call ChipU's SetPermission function 
with the desired n, R s , P D and S k [Ru|Rs|Pd|C 2 ]. 

f. ChipU verifies the received signature against S k [Ru|Rs|Pd|C 2 ] and applies P D to P n if the 
25 signature matches 

g. System checks 1 st output parameter. 1 = success, 0 = failure. 

The data flow for authenticated writes to permissions is shown in Figure 336 below. 

8.5 Programming K 

30 In this case, we have a factory chip (ChipF) connected to a System. The System wants to program 
the key in another chip (ChipP). System wants to avoid passing the new key to ChipP in the clear, 
and also wants to avoid the possibility of the key-upgrade message being replayed on another 
ChipP (even if the user doesn't know the key). 

The protocol assumes that ChipF and ChipP already share a secret key Ko ld . This key is used to 
35 ensure that only a chip that knows Ko )d can set K^w 

The protocol requires the following publicly available functions in ChipP: 
RandomQ Returns R (does not advance R). 
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Knew 



SetPartialKey[X,Y] 



ReplaceKey[X, Y, Z] Replaces K by S K oid[R|X|C 3 ]0Y, advances R, and returns 1 only If 
S K oid[X|Y|C 3 ] = Z. Otherwise returns 0. The time taken to calculate 
signatures and compare values must be identical for all inputs. 
And the following data and function in ChipF: 
5 CountRemaining Part of M with contains the number of signatures that ChipF is 

allowed to generate. Decrements with each successful call to 
GetProgramKey. Permissions in P for this part of M needs to be 
Readonly once ChipF has been setup. Therefore can only be 
updated by a ChipS that has authority to perform updates to that part 
10 ofM. 

The new key to be transferred from ChipF to ChipP. Must not be 
visible. 

If word X of Knew has not yet been set, set word X of K new to Y and 
return 1 . Otherwise return 0. This function allows Knew to be pro- 
1 5 grammed in multiple steps, thereby allowing different people or 

systems to know different parts of the key (but not the whole Kn ew ). 
Knew is stored in ChipF's flash memory. Since there is a small 
number of ChipFs, it is theoretically not necessary to store the 
inverse of K new , but it is stronger protection to do so. 
20 GetProgramKey[X] Advances R F , decrements CountRemaining, outputs Rp, the 

encrypted key S Ko id[X|RF|C 3 ]®Knew and a signature of the first two 
outputs plus C 3 if CountRemaining>0. Otherwise outputs 0. The time 
to calculate the encrypted key & signature must be identical for all 
inputs. 

25 To update P's key : 

a. System calls ChipP's Random function; 

b. ChipP returns R P to System; 

c. System calls ChipFs GetProgramKey function, passing in the result from b; 

d. ChipF updates Rp, then calculates and returns Rp, S Ko id[Rp|RF|C 3 ]eKnew, and 

SKold[RF|SKold[Rp|RF|C 3 ]®Knew|C 3 ]; 

If the response from d is not 0, System calls ChipP's ReplaceKey function, passing in the 
response from d; 

f. System checks response from ChipP. If the response is 1 , then Kp has been correctly updated 
to Knew- If the response is 0, K P has not been updated. 
35 The data flow for key updates is shown in Figure 337. 



e. 
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Note that Knew is never passed in the open. An attacker could send its own Rp, but cannot produce 
SKoid[Rp|RF|C 3 ] without Koi d . The third parameter, a signature, is sent to ensure that ChipP can 
determine if either of the first two parameters have been changed en route. 



5 CountRemaining needs to be setup in M F (including making it Readonly in P) before ChipF is 

programmed with K P . ChipF should therefore be programmed to only perform a limited number of 
GetProgramKey operations (thereby limiting compromise exposure if a ChipF is stolen). An 
authorized ChipS can be used to update this counter if neccesary (see Section 8.4 on page 665). 

10 8.5.1 Chicken and Egg 

Of course, for the Program Key protocol to work, both ChipF and ChipP must both know Ko, d . 
Obviously both chips had to be programmed with Kqw, and thus Kqw can be thought of as an older 
Knew: Koid can be placed in chips if another ChipF knows Koider, and so on. 

1 5 Although this process allows a chain of reprogramming of keys, with each stage secure, at some 

stage the very first key (K nnst ) must be placed in the chips. K first is in fact programmed with the chip's 
microcode at the manufacturing test station as the last step in manufacturing test. K fiR5t can be a 
manufacturing batch key, changed for each batch or for each customer etc, and can have as short 
a life as desired. Compromising K first need not result in a complete compromise of the chain of Ks. 



9.1 Protocol background 

This protocol set is an extension to the single key single memory vector protocol set, and is 
provided for two reasons: 
25 o the multiple key multiple memory vector protocol set defined in this document is simply 
extensions of this one; and 
o it is useful in its own right 

The multiple key protocol set is typically useful for applications where there are multiple types of 
systems and consumables, and they need to work with each other in various ways. This is typically 
30 in the following situations: 

o when different systems want to share some consumables, but not others. For example 

printer models may share some ink cartridges and not share others. 
© when there are different owners of data in M. Part of the memory vector may be owned by 
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one company (eg the speed of the printer) and another may be owned by another (eg the 
serial number of the chip). In this case a given key K„ needs to be able to write to a given 
part of M, and other keys Kn need to be disallowed from writing to these same areas. 



9.2 



Requirements of protocol 
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Each OA Chip contains the following values: 

N The maximum number of keys known to the chip. 

Kn Array of N secret keys used for calculating F^IX] where Kn is the nth element of the 

array. Each K„ must not be stored directly in the OA Chip . Instead, each chip needs to 
5 store a single random number R K (different for each chip), Kn©R K , and -.Kn®R K . The 

stored K^Rk can be XORed with Rk to obtain the real Kp. Although -.K^Rk must be 

stored to protect against differential attacks, it is not used. 
R Current random number used to ensure time varying messages. Each chip instance 

must be seeded with a different initial value. Changes for each signature generation. 
10 M Memory vector of QA Chip. A fixed part of M contains N in Readonly form so users of 

the chip can know the number of keys known by the chip. 
P N+1 element array of access permissions for each part of M. Entry 0 holds access 

permissions for non-authenticated writes to M (no key required). Entries 1 to N+1 hold 

access permissions for authenticated writes to M, one for each K. Permission choices 
1 5 for each part of M are Read Only, Read/Write, and Decrement Only. 

C 3 constants used for generating signatures. C 1f C 2 , and C 3 are constants that pad out a 

submessage to a hashing boundary, and all 3 must be different. 

Each QA Chip contains the following private function: 
20 S Kn [N,X] Internal function only. Returns S Kn [X], the result of applying a digital signature function S 
to X based upon the appropriate key K n . The digital signature must be long enough to 
counter the chances of someone generating a random signature. The length depends 
on the signature scheme chosen, although the scheme chosen for the QA Chip is 
HMAC-SHA1 (see Section 1 3 on page 691 ), and therefore the length of the signature is 
25 160 bits. 

Additional functions are required in certain QA Chips, but these are described as required. 

9.3 Reads 

As with the single key scenario, we have a trusted chip (ChipT) connected to a System. The 
30 System wants to authenticate an object that contains a non-trusted chip (ChipA). In effect, the 

System wants to know that it can securely read a memory vector (M) from ChipA: to be sure that 
ChipA is valid and that M has not been altered. 
The protocol requires the following publicly available functions: 
RandomQ Returns R (does not advance R). 
35 Read[n, X] Advances R, and returns R, M, SKn[X|R|Ci|M]. The time taken to calculate the 

signature must not be based on the contents of X, R, M, or K. 
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Test[n,X f Y, Z] Advances R and returns 1 if SKn[R|X|d|Y] = Z. Otherwise returns 0. The time 
taken to calculate and compare signatures must be independent of data content. 

To authenticate ChipA and read ChipA's memory M: 
5 a. System calls ChipT's Random function; 

b. ChipT returns R T to System; 

c. System calls ChipA's Read function, passing in some key number n1 and the result from b; 

d. ChipA updates R A , then calculates and returns R A , M A , SkahiIRtIRaICiIMa]; 

e. System calls ChipT's Test function, passing in n2, R A , M A , SKAnitR-rlRAldlM/O; 

10 f. System checks response from ChipT. If the response is 1 , then ChipA is considered authentic. If 
0, ChipA is considered invalid. 

The choice of n1 and n2 must be such that ChipA's Km = ChipT's K^. 

1 5 The data flow for read authentication is shown in Figure 338. 

The protocol allows System to simply pass data from one chip to another, with no special 
processing. The protection relies on ChipT being trusted, even though System does not know K. 

20 When ChipT is physically separate from System (eg is chip on a board connected to System) 

System must also occassionally (based on system clock for example) call ChipT's Test function 
with bad data, expecting a 0 response. This is to prevent someone from inserting a fake ChipT into 
the system that always returns 1 for the Test function. 

25 It is important that n1 is chosen by System. Otherwise ChipA would need to return N A sets of 

signatures for each read, since ChipA does not know which of the keys will satisfy ChipT. Similarly, 
system must also choose n2, so it can potentially restrict the number of keys in ChipT that are 
matched against (otherwise ChipT would have to match against all its keys). This is important in 
order to restrict how different keys are used. For example, say that ChipT contains 6 keys, keys 0-2 

30 are for various printer-related upgrades, and keys 3-6 are for inks. ChipA contains say 4 keys, one 
key for each printer model. At power-up, System goes through each of chipA's keys 0-3, trying each 
out against ChipT's keys 3-6. System doesn't try to match against ChipT's keys 0-2. Otherwise 
knowledge of a speed-upgrade key could be used to provide ink OA Chip chips. This matching 
needs to be done only once (eg at power up). Once matching keys are found, System can continue 

35 to use those key numbers. 
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Since System needs to know N T and N A , part of M is used to hold N (eg in Read Only form), and 
the system can obtain it by calling the Read function, passing in key 0. 



9.4 Writes 

5 As with the single key scenario, the System wants to update M in ChipU. As before, this can be 
done in a non-authenticated and authenticated way. 

9.4.1 Non-authenticated writes 

This is the most frequent type of write, and takes place between the System / consumable during 
1 0 normal everyday operation. In this kind of write, System wants to change M subject to P. For 
example, the System could be decrementing the amount of consumable remaining. Although 
System does not need to know any of the Ks or even have access to a trusted chip to perform the 
write, System must follow a non-authenticated write by an authenticated read if it needs to know 
that the write was successful. 
1 5 The protocol requires the following publicly available function: 

Write[X] Writes X over those parts of M subject to P 0 and the existing value for M. 

To authenticate a write of M new to ChipA's memory M: 
a. System calls ChiplTs Write function, passing in M new ; 
20 b. The authentication procedure for a Read is carried out (see Section 9.3 on page 671 ); 
c. If ChipU is authentic and = M returned in b, the write succeeded. If not, it failed. 

9.4.2 Authenticated writes 

In this kind of write, System wants to change Chip U's M in an authorized way, without being 
25 subject to the permissions that apply during normal operation (P 0 ). For example, the consumable 
may be at a refilling station and the normally Decrement Only section of M should be updated to 
include the new valid consumable. In this case, the chip whose M is being updated must 
authenticate the writes being generated by the external System and in addition, apply the 
appropriate permission for the key to ensure that only the correct parts of M are updated. Having a 
30 different permission for each key is required as when multiple keys are involved, all keys should not 
necessarily be given open access to M. For example, suppose M contains printer speed and a 
counter of money available for franking. A ChipS that updates printer speed should not be capable 
of updating the amount of money. Since P 0 is used for non-authenticated writes, each Kn has a 
corresponding permission P n+ i that determines what can be updated in an authenticated write. 

35 

In this transaction protocol, the System's chip is referred to as ChipS, and the chip being updated is 
referred to as ChipU. Each chip distrusts the other. 
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The protocol requires the following publicly available functions in ChipU: 

Read[n t X] Advances R, and returns R, M, S|<n[X|R|Ci|M]. The time taken to calculate 

the signature must not be based on the contents of X, R, M, or K. 
WriteA[n, X, Y, Z] Advances R, replaces M by Y subject to P n+1 , and returns 1 only if 
5 S K n[R|X|d|Y] = Z. Otherwise returns 0. The time taken to calculate and 

compare signatures must be independent of data content. This function is 
identical to ChipTs Test function except that it additionally writes Y subject 
to Pn+T to its M when the signature matches. 
Authenticated writes require that the System has access to a ChipS that is capable of gen- 
1 0 erating appropriate signatures. ChipS requires the following variables and function: 

CountRemaining Part of M that contains the number of signatures that ChipS is allowed to 
generate. Decrements with each successful call to SignM and SignP. 
Permissions in ChipS's P 0 for this part of M needs to be Readonly once 
ChipS has been setup. Therefore CountRemaining can only be updated by 
1 5 another ChipS that will perform updates to that part of M (assuming 

ChipS's P allows that part of M to be updated). 
Q Part of M that contains the write permissions for updating ChipU's M. By 

adding Q to ChipS we allow different ChipSs that can update different parts 
of My. Permissions in ChipS's P 0 for this part of M needs to be Readonly 
20 once ChipS has been setup. Therefore Q can only be updated by another 

ChipS that will perform updates to that part of M. 
SignM[n,V,W,X,Y,Z] Advances R, decrements CountRemaining and returns R, Zqx (Z applied to 
X with permissions Q), SKntWIRIdlZox] only if Y= S|<n[V|W|Ci|X] and 
CountRemaining > 0. Otherwise returns all 0s. The time taken to calculate 
25 and compare signatures must be independent of data content. 



To update ChipU's M vector: 

a. System calls ChipU's Read function, passing in n1 and 0 as the input parameters; 

b. ChipU produces Ry, My, SKnitOIRulC^Mu] and returns these to System; 

30 c. System calls ChipS's SignM function, passing in n2 (the key to be used in ChipS), 0 (as used in 
a), Ru, M Uf SKnitOIRuldlMu], and M D (the desired vector to be written to ChipU); 

d. ChipS produces Rs, M QD (processed by running M D against Mu using Q) and SKn2[Ru|Rs|Ci|M QD ] 
if the inputs were valid, and 0 for all outputs if the inputs were not valid. 

e. If values returned in d are non zero, then ChipU is considered authentic. System can then call 
35 ChipU's WriteA function with these values from d. 

f. ChipU should return a 1 to indicate success. A 0 should only be returned if the data generated 
by ChipS is incorrect (e.g. a transmission error). 
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The choice of n1 and n2 must be such that ChipU's Kni = ChipS's K^. 

The data flow for authenticated writes is shown in Figure 339 below. 

5 Note that Q in ChipS is part of ChipS's M. This allows a user to set up ChipS with a permission set 
for upgrades. This should be done to ChipS and that part of M designated by P 0 set to Readonly 
before ChipS is programmed with Ky. If K s is programmed with Ku first, there is a risk of someone 
obtaining a half-setup ChipS and changing all of Mu instead of only the sections specified by Q. 

10 In addition, CountRemaining in ChipS needs to be setup (including making it Readonly in P s ) 
before ChipS is programmed with K y . ChipS should therefore be programmed to only perform a 
limited number of SignM operations (thereby limiting compromise exposure if a ChipS is stolen). 
Thus ChipS would itself need to be upgraded with a new CountRemaining every so often. 

1 5 9.4.3 Updating permissions for future writes 

In order to reduce exposure to accidental and malicious attacks on P (and certain parts of M), only 
authorized users are allowed to update P. Writes to P are the same as authorized writes to M, 
except that they update P n instead of M. Initially (at manufacture), P is set to be Read/Write for all 
parts of M. As different processes fill up different parts of M, they can be sealed against future 

20 change by updating the permissions. Updating a chip's P 0 changes permissions for unauthorized 
writes, and updating P n+1 changes permissions for authorized writes with key Kn. 

P n is only allowed to change to be a more restrictive form v of itself. For example, initially all parts of 
M have permissions of Read/Write. A permission of Read/Write can be updated to Decrement Only 
25 or Read Only. A permission of Decrement Only can be updated to become Read Only. A Read 
Only permission cannot be further restricted. 

In this transaction protocol, the System's chip is referred to as ChipS, and the chip being updated is 
referred to as ChipU. Each chip distrusts the other. 

30 The protocol requires the following publicly available functions in ChipU: 
RandomQ Returns R (does not advance R). 

SetPermission[n,p,X,Y,Z] Advances R, and updates P p according to Y and returns 1 followed by the 
resultant P p only if S Kn [R|X|Y|C 2 ] = Z. Otherwise returns 0. P p can only become 
more restricted. Passing in 0 for any permission leaves it unchanged (passing in 
35 Y=0 returns the current P p ). 



675 



Authenticated writes of permissions require that the System has access to a ChipS that is capable 
of generating appropriate signatures. ChipS requires th following variables and function: 
CountRemaining Part of M that contains the number of signatures that ChipS is allowed to 

generate. Decrements with each successful call to SignM and SignP. 
Permissions in ChipS's P 0 for this part of M needs to be Readonly once 
ChipS has been setup. Therefore CountRemaining can only be updated by 
another ChipS that will perform updates to that part of M (assuming 
ChipS's P n allows that part of M to be updated). 
SignP[n,X,Y] Advances R, decrements CountRemaining and returns R and S Kn [X|R|Y|C 2 ] 

only if CountRemaining > 0. Otherwise returns all 0s. The time taken to 
calculate and compare signatures must be independent of data content. 

To update ChipU's P n : 

a. System calls ChipU's Random function; 

b. ChipU returns Ru to System; 

c. System calls ChipS's SignP function, passing in n1 , Ry and P D (the desired P to be written to 
ChipU); 

d. ChipS produces R s and S K ni[Ru|RsPD|C 2 ] if it is still permitted to produce signatures. 

e. If values returned in d are non zero, then System can then call ChipU's SetPermission function 
with n2, the desired permission entry p, R s , P D and S Kn i[Ru|Rs|PD|C2]. 

f. ChipU verifies the received signature against S Kn 2[Ru|Rs|PD|C 2 ] and applies P D to P n if the 
signature matches 

g. System checks 1st output parameter. 1 = success, 0 = failure. 

The choice of n1 and n2 must be such that ChipU's Km = ChipS's K,*. 

The data flow for authenticated writes to permissions is shown in Figure 340 below. 

9.4.4 Protecting M in a multiple key system 

To protect the appropriate part of M, the SetPermission function must be called after the part of M 
has been set to the desired value. 

For example, if adding a serial number to an area of M that is currently ReadWrite so that noone is 
permitted to update the number again: 

o the Write function is called to write the serial number to M 

o SetPermission is called for n = {1 , N} to set that part of M to be Readonly for authorized 
writes using key n-1 . 
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o SetPermission is called for 0 to set that part of M to be Readonly for non-authorized writes 

For example, adding a consumable value to M such that only keys 1-2 can update it, and keys 0, 
and 3-N cannot: 

o the Write function is called to write the amount of consumable to M 

o SetPermission is called for n = {1 , 4, 5, .... N-1} to set that part of M to be Readonly for 

authorized writes using key n-1 . This leaves keys 1 and 2 with ReadWrite permissions, 
o SetPermission is called for 0 to set that part of M to be DecrementOnly for non-authorized 

writes. This allows the amount of consumable to decrement. 

It is possible for someone who knows a key to further restrict other keys, but it is not in anyone's 
interest to do so. 

9.5 Programming K 

In this case, we have a factory chip (ChipF) connected to a System. The System wants to program 
the key in another chip (ChipP). System wants to avoid passing the new key to ChipP in the clear, 
and also wants to avoid the possibility of the key-upgrade message being replayed on another 
ChipP (even if the user doesn't know the key). 

The protocol is a simple extension of the single key protocol in that it assumes that ChipF and 
ChipP already share a secret key K^. This key is used to ensure that only a chip that knows Koi<j 
can set K^w 

The protocol requires the following publicly available functions in ChipP: 
RandomQ Returns R (does not advance R). 

ReplaceKey[n, X, Y, Z] Replaces Kn by S K n[R|X|C 3 ]©Y, advances R, and returns 1 only if 

S K n[X|Y|C 3 ] = Z. Otherwise returns 0. The time taken to calculate sig- 
natures and compare values must be identical for all inputs. 

And the following data and functions in ChipF: 

CountRemaining Part of M with contains the number of signatures that ChipF is allowed 

to generate. Decrements with each successful call to GetProgramKey. 

Permissions in P for this part of M needs to be Readonly once ChipF 

has been setup. Therefore can only be updated by a ChipS that has 

authority to perform updates to that part of M. 
Knew The new key to be transferred from ChipF to ChipP. Must not be visible. 
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SetPartialKey[X,Y] 



10 



GetProgramKeyfn, X] 



If word X of Knew has not yet been set, set word X of Knew to Y and return 
1. Otherwise return 0. This function allows Knew to be programmed in 
multiple steps, thereby allowing different people or systems to know 
different parts of the key (but not the whole Knew). Knew is stored in 
ChipF's flash memory. Since there is a small number of ChipFs, it is 
theoretically not necessary to store the inverse of Knew, but it is stronger 
protection to do so. 

Advances R F , decrements CountRemaining, outputs Rp, the encrypted 
key SKn[X|RF|C 3 ]©Knew and a signature of the first two outputs plus C 3 if 
CountRemaining>0. Otherwise outputs 0. The time to calculate the 
encrypted key & signature must be identical for all inputs. 



To update P's key : 

a. System calls ChipP's Random function; 
15 b. ChipP returns Rp to System; 

c. System calls ChipFs GetProgramKey function, passing in n1 (the desired key to use) and the 
result from b; 

d. ChipF updates R F , then calculates and returns R F , SKni[Rp|RF|C 3 ]®Knew, and 

SKnl[RF|SKnl[Rp|RF|C3]©Knew|C3]; 

20 e. If the response from d is not 0, System calls ChipP's ReplaceKey function, passing in n2 (the 
key to use in ChipP) and the response from d; 
f. System checks response from ChipP. If the response is 1 , then K Pn2 has been correctly updated 
to Knew- If the response is 0, K Pn2 has not been updated. 



25 The choice of n1 and n2 must be such that ChipF's K n1 = ChipP's K n2 . 



The data flow for key updates is shown in Figure 341 below. 

Note that Kn ew is never passed in the open. An attacker could send its own Rp, but cannot produce 
30 SKni[Rp|RF|C 3 ] without Km. The signature based on Knew is sent to ensure that ChipP will be able to 
determine if either of the first two parameters have been changed en route. 
CountRemaining needs to be setup in M F (including making it Readonly in P) before ChipF is 
programmed with Kp. ChipF should therefore be programmed to only perform a limited number of 
GetProgramKey operations (thereby limiting compromise exposure if a ChipF is stolen). An 
35 authorized ChipS can be used to update this counter if neccesary (see Section 9.4 on page 673). 



9.5.1 Chicken and Egg 
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As with the single key protocol, for the Program Key protocol to work, both ChipF and ChipP must 
both know Ko W . Obviously both chips had to be programmed with Kow, and thus Ko, d can be thought 
of as an older K^: Ko, d can be placed in chips if another ChipF knows Kower, and so on. 

5 Although this process allows a chain of reprogramming of keys, with each stage secure, at some 
stage the very first key (K first ) must be placed in the chips. K first is in fact programmed with the chip's 
microcode at the manufacturing test station as the last step in manufacturing test. K firet can be a 
manufacturing batch key, changed for each batch or for each customer etc, and can have as short 
a life as desired. Compromising K firs t need not result in a complete compromise of the chain of Ks. 

10 

Depending on the reprogramming requirements, K firs t can be the same or different for all K n . 

10 Multiple Keys Multiple Memory Vectors 

1 0.1 Protocol background 
1 5 This protocol set is a slight restriction of the multiple key single memory vector protocol set, and is 
the expected protocol. It is a restriction in that M has been optimized for Flash memory utilization. 

M is broken into multiple memory vectors (semi-fixed and variable components) for the purposes of 
optimizing flash memory utilization. Typically M contains some parts that are fixed at some stage of 
20 the manufacturing process (eg a batch number, serial number etc), and once set, are not ever 

updated. This information does not contain the amount of consumable remaining, and therefore is 
not read or written to with any great frequency. 

We therefore define M 0 to be the M that contains the frequently updated sections, and the 
25 remaining Ms to be rarely written to. Authenticated writes only write to M 0 , and non-authenticated 
writes can be directed to a specific M n . This reduces the size of permissions that are stored in the 
OA Chip (since key-based writes are not required for Ms other than M 0 ). It also means that M 0 and 
the remaining Ms can be manipulated in different ways, thereby increasing flash memory longevity. 

30 10.2 Requirements of protocol 

Each QA Chip contains the following values: 

N The maximum number of keys known to the chip. 

T The number of vectors M is broken into. 

Kn Array of N secret keys used for calculating FKn[X] where K„ is the nth element of the array. 
35 Each Kn must not be stored directly in the QA Chip . Instead, each chip needs to store a single 
random number Rk (different for each chip), Kn©R K , and -.K n ®R K . The stored K^Rk can be 
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XORed with Rk to obtain the real Although -.K^Rk must be stored to protect against differential 
attacks, it is not used. 

R Current random number used to ensure time varying messages. Each chip instance must be 
seeded with a different initial value. Changes for each signature generation. 
5 M T Array of T memory vectors. Only M 0 can be written to with an authorized write, while all Ms 
can be written to in an unauthorized write. Writes to M 0 are optimized for Flash usage, while 
updates to any other M n are expensive with regards to Flash utilization, and are expected to be only 
performed once per section of M n . contains T and N in Readonly form so users of the chip can 
know these two values. 

1 0 Pt+n T+N element array of access permissions for each part of M. Entries n={0... T-1} hold access 
permissions for non-authenticated writes to M n (no key required). Entries n={T to T+N-1}hold 
access permissions for authenticated writes to M 0 for Kn. Permission choices for each part of M are 
Read Only, Read/Write, and Decrement Only. 

C 3 constants used for generating signatures. C 1t C 2 , and C 3 are constants that pad out a 
1 5 submessage to a hashing boundary, and all 3 must be different. 

Each OA Chip contains the following private function: 

S Kn [N,X] Internal function only. Returns SkoIX], the result of applying a digital signature 

function S to X based upon the appropriate key K n . The digital signature must be 
20 long enough to counter the chances of someone generating a random signature. 

The length depends on the signature scheme chosen, although the scheme 
chosen for the OA Chip is HMAC-SHA1 , and therefore the length of the signature 
is 160 bits. 

25 Additional functions are required in certain QA Chips, but these are described as required. 
10.3 Reads 

As with the previous scenarios, we have a trusted chip (ChipJ) connected to a System. The System 
wants to authenticate an object that contains a non-trusted chip (ChipA). In effect, the System 
30 wants to know that it can securely read a memory vector (M t ) from ChipA: to be sure that ChipA is 
valid and that M has not been altered. 

The protocol requires the following publicly available functions: 
RandomQ Returns R (does not advance R). 

Read[n, t, X] Advances R, and returns R, M t , SKnlXIRjdlMJ. The time taken to calculate the 
35 signature must not be based on the contents of X, R, M t , or K. If t is 

invalid, the function assumes t=0. 
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Test[n,X, Y, 2] Advances R and returns 1 If SKnfRIXICilY] = Z. Otherwise returns 0. The 
time taken to calculate and compare signatures must be independent of 
data content. 

5 To authenticate ChipA and read ChipA's memory M: 

a. System calls ChipTs Random function; 

b. ChipT returns R T to System; 

c. System calls ChipA's Read function, passing in some key number n1, the desired M number 
t, and the result from b; 

10 d. ChipA updates R Al then calculates and returns R A , M A t, Sk^iIRtIRaICiIM/u]; 

e. System calls ChipTs Test function, passing in n2, R A , M At , SK^ifR-rlR/vlCilMAt]; 

f. System checks response from ChipT. If the response is 1, then ChipA is considered 
authentic. If 0, ChipA is considered invalid. 

1 5 The choice of n1 and n2 must be such that ChipA's = ChipTs K^. 

The data flow for read authentication is shown in Figure 342 below. 

The protocol allows System to simply pass data from one chip to another, with no special 
20 processing. The protection relies on ChipT being trusted, even though System does not know K. 

When ChipT is physically separate from System (eg is chip on a board connected to System) 
System must also occassionally (based on system clock for example) call ChipT's Test function 
with bad data, expecting a 0 response. This is to prevent someone from inserting a fake ChipT into 
25 the system that always returns 1 for the Test function. 

It is important that n1 is chosen by System. Otherwise ChipA would need to return N A sets of 
signatures for each read, since ChipA does not know which of the keys will satisfy ChipT. Similarly, 
system must also choose n2, so it can potentially restrict the number of keys in ChipT that are 

30 matched against (otherwise ChipT would have to match against all its keys). This is important in 

order to restrict how different keys are used. For example, say that ChipT contains 6 keys, keys 0-2 
are for various printer-related upgrades, and keys 3-6 are for inks. ChipA contains say 4 keys, one 
key for each printer model. At power-up, System goes through each of chipA's keys 0-3, trying each 
out against ChipT's keys 3-6. System doesn't try to match against ChipTs keys 0-2. Otherwise 

35 knowledge of a speed-upgrade key could be used to provide ink OA Chip chips. This matching 

needs to be done only once (eg at power up). Once matching keys are found, System can continue 
to use those key numbers. 
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Since System needs to know N T , IM A , and T A , part of Mi is used to hold N (eg in Read Only form), 
and the system can obtain it by calling the Read function, passing in key 0 and t=1 . 

10.4 Writes 

5 As with the previous scenarios, the System wants to update M t in ChipU. As before, this can be 
done in a non-authenticated and authenticated way. 

1 0.4.1 Non-authenticated writes 

This is the most frequent type of write, and takes place between the System / consumable during 
1 0 normal everyday operation for M 0 , and during the manufacturing process for M t . 

In this kind of write, System wants to change M subject to P. For example, the System could be 
decrementing the amount of consumable remaining. Although System does not need to know and 
of the Ks or even have access to a trusted chip to perform the write, System must follow a non- 
1 5 authenticated write by an authenticated read if it needs to know that the write was successful. 

The protocol requires the following publicly available function: 

Write[t, X] Writes X over those parts of M t subject to P t and the existing value 

for M. 

20 

To authenticate a write of M new to ChipA's memory M: 

a. System calls ChipU's Write function, passing in Mne W ; 

b. The authentication procedure for a Read is carried out (see Section 9.3 on page 671 ); 

c. If ChipU is authentic and M new = M returned in b, the write succeeded. If not, it failed. 

25 

1 0.4.2 Authenticated writes 

In the multiple memory vectors protocol, only M 0 can be written to an an authenticated way. This is 
because only M 0 is considered to have components that need to be upgraded. 

30 In this kind of write, System wants to change Chip ITs M 0 in an authorized way, without being 

subject to the permissions that apply during normal operation. For example, the consumable may 
be at a refilling station and the normally Decrement Only section of M 0 should be updated to include 
the new valid consumable. In this case, the chip whose M 0 is being updated must authenticate the 
writes being generated by the external System and in addition, apply the appropriate permission for 

35 the key to ensure that only the correct parts of M 0 are updated. Having a different permission for 
each key is required as when multiple keys are involved, all keys should not necessarily be given 
open access to M 0 . For example, suppose M 0 contains printer speed and a counter of money 
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available for franking. A ChipS that updates printer speed should not be capable of updating the 
amount of money. Since P 0 .„t-i is used for non-authenticated writes, each K„ has a corresponding 
permission P T+n that determines what can be updated in an authenticated write. 

5 In this transaction protocol, the System's chip is referred to as ChipS, and the chip being updated is 
referred to as ChipU. Each chip distrusts the other. 

The protocol requires the following publicly available functions in ChipU: 

Read[n, t, X] Advances R, and returns R, M t , S Kn [X|R|Ci|Mt]. The time taken to cal- 

1 0 culate the signature must not be based on the contents of X, R, M t , 

or K. 

WriteA[n, X, Y, Z] Advances R, replaces M 0 by Y subject to P T+n , and returns 1 only if 

SKnfRIXICilY] = Z. Otherwise returns 0. The time taken to calculate 
and compare signatures must be independent of data content. This 
1 5 function is identical to ChipTs Test function except that it additionally 

writes Y subject to P T+n to its M when the signature matches. 

Authenticated writes require that the System has access to a ChipS that is capable of generating 
appropriate signatures. ChipS requires the following variables and function: 

20 CountRemaining Part of M that contains the number of signatures that ChipS is 

allowed to generate. Decrements with each successful call to SignM 
and SignP. Permissions in ChipS's P 0 ..-m for this part of M needs to 
be Readonly once ChipS has been setup. Therefore 
CountRemaining can only be updated by another ChipS that will 

25 perform updates to that part of M (assuming ChipS's P allows that 

part of M to be updated). 
Q Part of M that contains the write permissions for updating ChipU's M. 

By adding Q to ChipS we allow different ChipSs that can update 
different parts of My. Permissions in ChipS's P 0 ..t-i for this part of M 

30 needs to be Readonly once ChipS has been setup. Therefore Q can 

only be updated by another ChipS that will perform updates to that 
part of M. 

SignM[n,V,W,X,Y,Z] Advances R, decrements CountRemaining and returns R, Zqx (Z 

applied to X with permissions Q), SKnlWIRIC-JZox] only if Y = 
35 SnntVIWICilX] and CountRemaining > 0. Otherwise returns all 0s. 

The time taken to calculate and compare signatures must be 
independent of data content. 
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To update ChipU's M vector: 

a. System calls ChipU's Read function, passing in n1 , 0 and 0 as the input parameters; 

b. ChipU produces Ru, M uo , SKnitOIRulCilMuo] and returns these to System; 

5 c. System calls ChipS's SignM function, passing in n2 (the key to be used in ChipS), 0 (as used in 
a), Ru, M uo , SKn^OIRulCilMuo], and M D (the desired vector to be written to ChipU); 

d. ChipS produces R Sl M QD (processed by running M D against M uo using Q) and 
SKn2[Ru|Rs|Ci|M QD ] if the inputs were valid, and 0 for all outputs if the inputs were not valid. 

e. If values returned in d are non zero, then ChipU is considered authentic. System can then call 
1 0 ChipU's WriteA function with these values from d. 

f. ChipU should return a 1 to indicate success. A 0 should only be returned if the data generated 
by ChipS is incorrect (e.g. a transmission error). 

The choice of n1 and n2 must be such that ChipU's K n1 = ChipS's K n 2- 

15 

The data flow for authenticated writes is shown in Figure 343 below. 

Note that Q in ChipS is part of ChipS's M. This allows a user to set up ChipS with a permission set 
for upgrades. This should be done to ChipS and that part of M designated by Po./m set to Readonly 
20 before ChipS is programmed with K u . If K s is programmed with K u first, there is a risk of someone 
obtaining a half-setup ChipS and changing all of M u instead of only the sections specified by Q. 

In addition, CountRemaining in ChipS needs to be setup (including making it Readonly in P s ) 
before ChipS is programmed with K U( ChipS should therefore be programmed to only perform a 
25 limited number of SignM operations (thereby limiting compromise exposure if a ChipS is stolen). 
Thus ChipS would itself need to be upgraded with a new CountRemaining every so often. 

10.4.3 Updating permissions for future writes 

In order to reduce exposure to accidental and malicious attacks on P (and certain parts of M), only 
30 authorized users are allowed to update P. Writes to P are the same as authorized writes to M, 

except that they update P n instead of M. Initially (at manufacture), P is set to be Read/Write for all 
M. As different processes fill up different parts of M, they can be sealed against future change by 
updating the permissions. Updating a chip's Po.t-i changes permissions for unauthorized writes to 
M n , and updating P T . t+n-1 changes permissions for authorized writes with key Kp. 

35 

P n is only allowed to change to be a more restrictive form of itself. For example, initially all parts of 
M have permissions of Read/Write. A permission of Read/Write can be updated to Decrement Only 
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or Read Only. A permission of Decrement Only can be updated to become Read Only. A Read 
Only permission cannot be further restricted. 



In this transaction protocol, the System's chip is referred to as ChipS, and the chip being updated is 
5 referred to as ChipU. Each chip distrusts the other. 

The protocol requires the following publicly available functions in ChipU: 
RandomQ Returns R (does not advance R). 

SetPermission[n,p,X,Y,Z] Advances R, and updates P p according to Y and returns 1 followed by 
1 0 the resultant P p only if SKn[R|X|Y|C 2 ] = Z. Otherwise returns 0. P p 

can only become more restricted. Passing in 0 for any permission 
leaves it unchanged (passing in Y=0 returns the current P p ). 
Authenticated writes of permissions require that the System has access to a ChipS that is capable 
of generating appropriate signatures. ChipS requires the following variables and function: 

15 

CountRemaining Part of ChipS's M 0 that contains the number of signatures that 

ChipS is allowed to generate. Decrements with each successful call 
to SignM and SignP. Permissions in ChipS's P 0 ..t-i for this part of 
M 0 needs to be Readonly once ChipS has been setup. Therefore 

20 CountRemaining can only be updated by another ChipS that will 

perform updates to that part of M 0 (assuming ChipS's P n allows that 
part of M 0 to be updated). 
SignP[n,X,Y] Advances R, decrements CountRemaining and returns R and 

S K n[X|R|Y|C 2 ] only if CountRemaining > 0. Otherwise returns all 0s. 

25 The time taken to calculate and compare signatures must be 

independent of data content. 

To update ChipLTs P n : 
a. System calls ChipU's Random function; 
30 b. ChipU returns Ry to System; 

c. System calls ChipS's SignP function, passing in n1, Ru and P D (the desired P to be written to 
ChipU); 

d. ChipS produces Rs and S K ni[Ru|RsFD|C 2 ] if it is still permitted to produce signatures. 

e. If values returned in d are non zero, then System can then call ChipU's SetPermission function 
35 with n2, the desired permission entry p, Rs, P D and SKni[Ru|Rs|PD|C 2 ]. 

f. ChipU verifies the received signature against S Kn 2[Ru|Rs|PD|C 2 ] and applies P D to P n if the 
signature matches 
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g. System checks 1st output parameter. 1 = success, 0 = failure. 
The choice of n1 and n2 must be such that ChipU's Kni = ChipS's K^. 
5 The data flow for authenticated writes to permissions is shown in Figure 344 below. 
10.4.4 Protecting M in a multiple key multiple M system 

To protect the appropriate part of M n against unauthorized writes, call SetPermissionsfn] for n = 0 to 
T-1 . To protect the appropriate part of M 0 against authorized writes with key n, call 
1 0 SetPermissions[T+n] for n=0 to N-1 . 

Note that only M 0 can be written in an authenticated fashion. 

Note that the SetPermission function must be called after the part of M has been set to the desired 
1 5 value. 

For example, if adding a serial number to an area of that is currently ReadWrite so that noone is 
permitted to update the number again: 

o the Write function is called to write the serial number to bA, 
20 o SetPermission(1 ) is called for to set that part of M to be Readonly for non-authorized writes. 

If adding a consumable value to M 0 such that only keys 1-2 can update it, and keys 0, and 3-N 
cannot: 

o the Write function is called to write the amount of consumable to M 
25 o SetPermission is called for 0 to set that part of M 0 to be DecrementOnly for non-authorized 

writes. This allows the amount of consumable to decrement. 
© SetPermission is called for n = {T, T+3, T+4 T+N-1} to set that part of M 0 to be Readonly 

for authorized writes using all but keys 1 and 2. This leaves keys 1 and 2 with ReadWrite 

permissions to M 0 . 

30 

It is possible for someone who knows a key to further restrict other keys, but it is not in anyone's 
interest to do so. 

10.5 Programming K 
35 This section is identical to the multiple key single memory vector ( Section 9.5 on page 677). It is 
repeated here with mention to M 0 instead of M for CountRemaining. 
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In this case, we have a factory chip (ChipF) connected to a System. The System wants to program 
the key in another chip (ChipP). System wants to avoid passing the new key to ChipP in the clear, 
and also wants to avoid the possibility of the key-upgrade message being replayed on another 
ChipP (even if the user doesn't know the key). 

The protocol is a simple extension of the single key protocol in that it assumes that ChipF and 
ChipP already share a secret key Kqw- This key is used to ensure that only a chip that knows Koi d 

Can Set Knew- 

The protocol requires the following publicly available functions in ChipP: 
Random □ Returns R (does not advance R). 

ReplaceKey[n, X, Y, Z] Replaces K,, by S Kn [R|X|C 3 ]eY, advances R, and returns 1 only if 

S Kn [X|Y|C 3 ] = Z. Otherwise returns 0. The time taken to calculate 
signatures and compare values must be identical for all inputs. 
And the following data and functions in ChipF: 

CountRemaining Part of M 0 with contains the number of signatures that ChipF is 

allowed to generate. Decrements with each successful call to 
GetProgramKey. Permissions in P for this part of M 0 needs to be 
Readonly once ChipF has been setup. Therefore can only be 
updated by a ChipS that has authority to perform updates to that 
part of M 0 . 

Knew The new key to be transferred from ChipF to ChipP. Must not be 

visible. 

SetPartialKey[X,Y] If word X of has not yet been set, set word X of Knew to Y and 

return 1 . Otherwise return 0. This function allows Knew to be pro- 
grammed in multiple steps, thereby allowing different people or 
systems to know different parts of the key (but not the whole K new ). 
Knew is stored in ChipF's flash memory. Since there is a small 
number of ChipFs, it is theoretically not necessary to store the 
inverse of Knew, but it is stronger protection to do so. 

GetProgramKey[n, X] Advances R F , decrements CountRemaining, outputs R F , the 

encrypted key SKn[X|R F |C 3 ]eKnew and a signature of the first two 
outputs plus C 3 if CountRemaining>0. Otherwise outputs 0. The 
time to calculate the encrypted key & signature must be identical 
for all inputs. 

To update P's key : 
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a. System calls ChipP's Random function; 

b. ChipP returns Rp to System; 

c. System calls ChipF's GetProgramKey function, passing in n1 (the desired key to use) and the 
result from b; 

5 d. ChipF updates R F , then calculates and returns Rp, SKni[Rp|RF|C3]©Knew, and 
S K ni[RF|SKni[Rp|RF|C3]eK new |C 3 ]; 

e. If the response from d is not 0, System calls ChipP's ReplaceKey function, passing in n2 (the 
key to use in ChipP) and the response from d; 

f. System checks response from ChipP. If the response is 1, then K Pn2 has been correctly updated 
10 to Knew. If the response is 0, Kp n2 has not been updated. 

The choice of n1 and n2 must be such that ChipF's K„i = ChipP's K^. 
The data flow for key updates is shown in Figure 345below. 

Note that K new is never passed in the open. An attacker could send its own Rp, but cannot produce 
S Kn i[Rp|RF|C 3 ] without K n i. The signature based on Knew is sent to ensure that ChipP will be able to 
1 5 determine if either of the first two parameters have been changed en route. 

CountRemaining needs to be setup in M F0 (including making it Readonly in P) before ChipF is 
programmed with K P . ChipF should therefore be programmed to only perform a limited number of 
GetProgramKey operations (thereby limiting compromise exposure if a ChipF is stolen). An 
authorized ChipS can be used to update this counter if neccesary (see Section 9.4 on page 673). 

20 

10.5.1 Chicken and Egg 

As with the single key protocol, for the Program Key protocol to work, both ChipF and ChipP must 
both know Koi d . Obviously both chips had to be programmed with Ko, d , and thus Koi d can be thought 
of as an older Kne W : Ko !d can be placed in chips if another ChipF knows Koi de r, and so on. 

25 

Although this process allows a chain of reprogramming of keys, with each stage secure, at some 
stage the very first key (K first ) must be placed in the chips. K fiR5t is in fact programmed with the chip's 
microcode at the manufacturing test station as the last step in manufacturing test. K fir5t can be a 
manufacturing batch key, changed for each batch or for each customer etc, and can have as short 
30 a life as desired. Compromising K fin5t need not result in a complete compromise of the chain of Ks. 
Depending on reprogramming requirements, K first can be the same or different for all K n . 

10.5.2 Security Note 

Different ChipFs should have different Rp values to prevent Knew from being determined as follows: 
35 The attacker needs 2 ChipFs, both with the same Rp and K„ but different values for Knew- By 

knowing Knewi the attacker can determine Knew2- The size of Rf is 2 160 , and assuming a lifespan of 
approximately 2 32 Rs, an attacker needs about 2 60 ChipFs with the same K„ to locate the correct 
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chip. Given that there are likely to be only hundreds of ChipFs with the same Kn, this is not a likely 
attack. The attack can be eliminated completely by making C 3 different per chip and transmitting it 
with the new signature. 

5 11 Summary of functions for all protocols 

All protocol sets, whether single key, multiple key, single M or multiple M, all rely on the same set of 
functions. The function set is listed here: 

11.1 All chips 

1 0 Since every chip must act as ChipP, ChipA and potentially ChipU, all chips require the following 
functions: 

• Random 

• ReplaceKey 

• Read 
1 5 • Write 

• WriteA 

• SetPermissions 

11.2 ChipT 

20 Chips that are to be used as ChipT also require: 

• Test 

11.3 Chips 

Chips that are to be used as ChipS also require either or both of: 
25 • SignM 

• SignP 

11.4 ChipF 

Chips that are to be used as ChipF also require: 
30 • SetPartialKey 

• GetProgramKey 

12 Remote Upgrades 

1 2. 1 Basic remote upgrades 
35 Regardless of the number of keys and the number of memory vectors, the use of authenticated 
reads and writes, and of replacing a new key without revealing Knew or Koid allows the possibility of 



689 



remote upgrades of ChipU and ChipP. The upgrade typically Involves a remote server and follows 
two basic steps: 

a. During the first stage of the upgrade, the remote system authenticates the user's system to 
ensure the user's system has the setup that it claims to have. 
5 b. During the second stage of the upgrade, the user's system authenticates the remote system 
to ensure that the upgrade is from a trusted source. 

12.1 .1 User requests upgrade 

The user requests that he wants to upgrade. This can be done by running a specific upgrade 
1 0 application on the user's computer, or by visiting a specific website. 

1 2.1 .2 Remote system gathers info securely about user's current setup 

In this step, the remote system determines the current setup for the user. The current setup must 
be authenticated, to ensure that the user truly has the setup that is claimed. Traditionally, this has 
1 5 been by checking the existence of files, generating checksums from those files, or by getting a 
serial number from a hardware dongle, although these traditional methods have difficulties since 
they can be generated locally by "hacked" software. 

The authenticated read protocol described in Section 8.3 on page 664 can be used to accomplish 
20 this step. The use of random numbers has the advantage that the local user cannot capture a 
successful transaction and play it back on another computer system to fool the remote system. 

1 2.1 .3 Remote system gives user choice of upgrade possibilities & user chooses 

If there is more than one upgrade possibility, the various upgrade options are now presented to the 
25 user. The upgrade options could vary based on a number of factors, including, but not limited to: 
o current user setup 

o user's preference for payment schemes (e.g. single payment vs. multiple payment) 
o number of other products owned by user 

30 The user selects an appropriate upgrade and pays if necessary (by some scheme such as via a 
secure web site). What is important to note here is that the user chooses a specific upgrade and 
commences the upgrade operation. 

1 2.1 .4 Remote system sends upgrade request to local system 

35 The remote system now instructs the local system to perform the upgrade. However, the local 
system can only accept an upgrade from the remote system if the remote system is also 
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authenticated. This is effectively an authenticated write. The use of Ru in the signature prevents the 
upgrade message from being replayed on another ChipU. 

If multiple keys are used, and each chip has a unique key, the remote system can use a serial 
5 number obtained from the current setup (authenticated by a common key) to lookup the unique key 
for use in the upgrade. Although the random number provides time varying messages, use of an 
unknown K that is different for each chip means that collection and examination of messages and 
their signatures is made even more difficult. 

10 12.2 OEM Upgrades 

OEM upgrades are effectively the same as remote upgrades, except that the user interacts with an 
OEM server for upgrade selection. The OEM server may send sub-requests to the manufacturer's 
remote server to provide authentication, upgrade availability lists, and base-level pricing 
information. 

15 

An additional level of authentication may be incorporated into the protocol to ensure that upgrade 
requests are coming from the OEM server, and not from a 3rd party. This can readily be 
incorporated into both authentication steps. 

20 13 Choice of Signature Function 

Given that all protocols make use of keyed signature functions, the choice of function is examined 
here. 

Table 232 outlines the attributes of the applicable choices (see Section 5.2 on page 629 and 
25 Section 5.5 on page 636 for more information). The attributes are phrased so that the attribute is 
seen as an advantage. 

Table 232. Attributes of Applicable Signature Functions 
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An examination of Table 232 shows that the choice is effectively between the 3 HMAC constructs 
and the Random Sequence. The problem of key size and key generation eliminates the Random 
Sequence. Given that a number of attacks have already been carried out on MD5 and since the 
5 hash result is only 128 bits, HMAC-MD5 is also eliminated. The choice is therefore between HMAC- 
SHA1 and HMAC-RIPEMD160. Of these, SHA-1 is the preferred function, since: 
© SHA-1 has been more extensively cryptanalyzed without being broken; 
o SHA-1 requires slightly less intermediate storage than RIPE-MD-160; 
o SHA-1 is algorithm ically less complex than RIPE-MD-160; 
1 0 Although SHA-1 is slightly faster than RIPE-MD-160, this was not a reason for choosing SHA-1 . 

13.1 HMAC-SHA1 

The mechanism for authentication is the HMAC-SHA1 algorithm. This section examines the HMAC- 
SHA1 algorithm in greater detail than covered so far, and describes an optimization of the algorithm 
1 5 that requires fewer memory resources than the original definition. 

13.1.1 HMAC 

Given the following definitions: 

o H = the hash function (e.g. MD5 or SHA-1 ) 

20 o n = number of bits output from H (e.g. 1 60 for SHA-1 , 1 28 bits for MD5) 

o M = the data to which the MAC function is to be applied 

o K = the secret key shared by the two parties 

o ipad = 0x36 repeated 64 times 



Only gives protection equivalent to 1 12-bit DES 
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o opad = 0x5C repeated 64 times 



The HMAC algorithm is as follows: 

a. Extend K to 64 bytes by appending 0x00 bytes to the end of K 

5 b. XOR the 64 byte string created in (1 ) with ipad 

c. append data stream M to the 64 byte string created in (2) 

d. Apply H to the stream generated in (3) 

e. XOR the 64 byte string created in (1 ) with opad 

f. Append the H result from (4) to the 64 byte string resulting from (5) 
10 g. Apply H to the output of (6) and output the result 

Thus: 

HMAC[M] = H[(K 0 opad) | H[(K 0 ipad) | M]] 

The HMAC-SHA1 algorithm is simply HMAC with H = SHA-1 . 

15 

13.1.2 SHA-1 

The SHA1 hashing algorithm is described in the context of other hashing algorithms in Section 
5.5.3.3 on page 640, and completely defined in [28]. The algorithm is summarized here. 
Nine 32-bit constants are defined in Table 233. There are 5 constants used to initialize the chaining 
20 variables, and there are 4 additive constants. 

Table 233. Constants used in SHA-1 



Initial Chaining Values 

fr, 0x67452301 

h 2 0XEFCDAB89 

h 3 0x9 8BADCFE 

h 4 0x10325476 

h 5 0XC3D2E1F0 



Additive Constants 

y 1 0x5A827999 

y 2 0X6ED9EBA1 

y 3 0X8F1BBCDC 

y 4 0XCA62C1D6 



Non-optimized SHA-1 requires a total of 2912 bits of data storage: 
25 o Five 32-bit chaining variables are defined: H 1f H 2 , H 3 , H 4 and H 5 . 
o Five 32-bit working variables are defined: A, B, C, D, and E. 
o One 32-bit temporary variable is defined: t. 
o Eighty 32-bit temporary registers are defined: Xo-79. 
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The following functions are defined for SHA-1 : 
Table 234. Functions used in SHA-1 

Symbolic Nomenclature Description 



+ Addition modulo 2 32 

X « Y Result of rotating X left through Y bit positions 

f(X, Y, Z) (X a Y) v (^X a Z) 

g(X, Y, Z) (X a Y) v (X a Z) v (Y a Z) 

h(X, Y, Z) X © Y © Z 



5 The hashing algorithm consists of firstly padding the input message to be a multiple of 512 bits and 
initializing the chaining variables with h-i_ 5 . The padded message is then processed in 512-bit 
chunks, with the output hash value being the final 160-bit value given by the concatenation of the 
chaining variables: H 1 | H 2 1 H 3 | H 4 | H 5 . 

1 0 The steps of the SHA-1 algorithm are now examined in greater detail. 

13.1.2.1 Step 1 . Preprocessing 

The first step of SHA-1 is to pad the input message to be a multiple of 512 bits as follows and to 
initialize the chaining variables. 

15 

Table 235. Steps to follow to preprocess the input message 



Pad the input message 


Append a 1 bit to the message 




Append 0 bits such that the length of the 
padded message is 64-bits short of a multiple 
of 512 bits. 


Append a 64-bit value containing the length in 
bits of the original input message. Store the 
length as most significant bit through to least 
significant bit. 


Initialize the chaining 
variables 


Hi <- h), H 2 <- /?2» H 3 <— h 3 , H 4 <r- /? 4 , H$ <— h 5 
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13.1.2.2 Step 2. Processing 

The padded input message is processed in 512-bit blocks. Each 512-bit block is in the form of 16 x 
32-bit words, referred to as lnputWordo_ 15 . 

5 Table 236. Steps to follow for each 51 2 bit block (lnputWordo.15) 



Copy the 512 input bits into 

Xo-15 


For j=0 to 15 

Xj = InputWordj 


Expand Xo-15 into X 16 _ 79 


Forj=16to 79 

Xj ((Xj_ 3 e x^ e Xj. 14 © x H6 ) « 1 ) 


Initialize working variables 


A <— H 1f B <- H 2 , C <- H 3 , D <- H 4 , E <— H 5 


Round 1 


Forj=0 to 19 

t +- ((A « 5) + f(B, C, D) + E + Xj + 

E <- D, D <- C, C <- (B « 30), B <- A, A <- t 


Round 2 


For j=20 to 39 

t <- ((A « 5) + h(B, C, D) + E + Xj + y 2 ) 

E <- D, D <- C, C <- (B « 30), B <- A, A <- t 


Round 3 


For j=40 to 59 

t <r- ((A « 5) + g(B, C, D) + E + Xj + y 3 ) 

E <- D, D <r- C, C (B « 30), B <- A, A <- t 


Round 4 


For j=60 to 79 

t <- ((A « 5) + h(B, C, D) + E + Xj + y 4 ) 

E <r- D, D <r- C, C <- (B « 30), B <- A, A <- t 


Update chaining variables 


<- H n + A, H 2 <- H 2 + B, 
H 3 <r- H 3 + C, H 4 H 4 + D, 
H 5 <- H 5 + E 



The bold text is to emphasize the differences between each round. 

10 13.1.2.3 Step 3. Completion 

After all the 512-bit blocks of the padded input message have been processed, the output hash 
value is the final 160-bit value given by: \ H 2 | H 3 | H 4 | H 5 . 

13.1.2.4 Optimization for hardware implementation 
1 5 The SHA-1 Step 2 procedure is not optimized for hardware. In particular, the 80 temporary 32-bit 
registers use up valuable silicon on a hardware implementation. This section describes an 
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optimization to the SHA-1 algorithm that only uses 16 temporary registers. The reduction in silicon 
is from 2560 bits down to 512 bits, a saving of over 2000 bits. It may not be important in some 
applications, but in the OA Chip storage space must be reduced where possible. 

5 The optimization is based on the fact that although the original 16-word message block is expanded 
into an 80-word message block, the 80 words are not updated during the algorithm. In addition, the 
words rely on the previous 16 words only, and hence the expanded words can be calculated on- 
the-fly during processing, as long as we keep 16 words for the backward references. We require 
rotating counters to keep track of which register we are up to using, but the effect is to save a large 
1 0 amount of storage. 

Rather than index X by a single value j, we use a 5 bit counter to count through the iterations. This 
can be achieved by initializing a 5-bit register with either 16 or 20, and decrementing it until it 
reaches 0. In order to update the 16 temporary variables as if they were 80, we require 4 indexes, 
1 5 each a 4-bit register. All 4 indexes increment (with wraparound) during the course of the algorithm. 

Table 237. Optimised Steps to follow for each 512 bit block (lnputWordo-15) 



Initialize working variables 


A <- Hi, B <- H 2 , C <- H 3 , D <— H 4 , E <— H 5 
Ni <- 1 3, N 2 *- 8, N 3 <- 2, N 4 <- 0 


Round 0 

Copy the 512 input bits into 

Xo-15 


Do 16 times 

X N4 = lnputWord N4 

[fK, fiN 2 , ftN 3 ] 0 ptional ftN 4 


Round 1A 


Do 16 times 

t <- ((A « 5) + f(B, C, D) + E + X N4 + y n ) 

[ftN lB ftN 2i fiN 3 ] 0 ptional ftN 4 

E <- D, D <- C, C <- (B « 30), B <— A, A <- t 


Round 1B 


Do 4 times 

Xn4 <— ((Xni ® Xn 2 © X N3 0 X N4 ) « 1 ) 
t <- ((A « 5) + f(B, C, D) + E + X N4 + y, ) 
ftNi, ftN 2 , flN 3 , ftN 4 

E <- D, D <- C, C <- (B « 30), B <- A, A <— t 


Round 2 


Do 20 times 

Xn4 *~ ((Xni ® X N2 ® X N3 ® X N4 ) « 1 ) 
t <- ((A « 5) + h(B, C, D) + E + X N4 + y 2 ) 
ftN 1f ftN 2 , ftN 3f ftN 4 
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E <r- D, D <- C, C <r- (B « 30), B <- A, A <- 1 


Round 3 


1— / W LI 1 1 1 CO 

Xn4 ((Xn1 © Xn2 © Xn3 © Xn4) « 1 ) 

t <- ((A « 5) + g(B, C, D) + E + X N4 + y 3 ) 
ftN 1t flN 2l ftN 3 , ftN 4 

E <- D, D <- C, C <- (B « 30), B <- A, A <- 1 


Rni inH 4 
r\uui ivj t 


Xn4 <— ((Xn1 © Xn2 © X N3 © Xn 4 ) « 1 ) 

t <- ((A « 5) + h(B, C, D) + E + X N4 + y 4 ) 
ftN^ ffN 2 , ftN 3 , 1tN 4 

E <- D, D <r- C, C <- (B « 30), B <- A, A <- t 


Update chaining variables 


H, <- H, + A, H 2 <- H 2 + B, 
H 3 <r- H 3 + C, H 4 <- H 4 + D, 
H 5 <- H 5 + E 



The bold text is to emphasize the differences between each round. 

The incrementing of N 1t N 2 , and N 3 during Rounds 0 and 1 A is optional. A software implementation 
5 would not increment them, since it takes time, and at the end of the 16 times through the loop, all 4 
counters will be their original values. Designers of hardware may wish to increment all 4 counters 
together to save on control logic. 

Round 0 can be completely omitted if the caller loads the 512 bits of Xo_i 5 . 

10 14 Holding Out Against Attacks 

The authentication protocols described in Section 7 on page 661 onward should be resistant to 
defeat by logical means. This section details each type of attack in turn with reference to the Read 
Authentication protocol. 

15 14.1 Brute force attack 

A brute force attack is guaranteed to break any protocol. However the length of the key means that 
the time for an attacker to perform a brute force attack is too long to be worth the effort. 

An attacker only needs to break K to build a clone authentication chip. A brute force attack on K 
20 must therefore break a 160-bit key. 
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An attack against K requires a maximum of 2 attempts, with a 50% chance of finding the key 
after only 2 159 attempts. Assuming an array of a trillion processors, each running one million tests 
per second, 2 159 (7.3 x 10 47 ) tests takes 2.3 x 10 22 years, which is longer than the total lifetime of 
the universe. There are around 100 million personal computers in the world. Even if these were all 
5 connected in an attack (e.g. via the Internet), this number is still 10,000 times smaller than the 

trillion-processor attack described. Further, if the manufacture of one trillion processors becomes a 
possibility in the age of nanocomputers, the time taken to obtain the key is still longer than the total 
lifetime of the universe. 

10 1 4.2 Guessing the key attack 

It is theoretically possible that an attacker can simply "guess the key". In fact, given enough time, 
and trying every possible number, an attacker will obtain the key. This is identical to the brute force 
attack described above, where 2 159 attempts must be made before a 50% chance of success is 
obtained. 

15 

The chances of someone simply guessing the key on the first try is 2 160 . For comparison, the 
chance of someone winning the top prize in a U.S. state lottery and being killed by lightning in the 
same day is only 1 in 2 61 [78]. The chance of someone guessing the authentication chip key on the 
first go is 1 in 2 160 , which is comparable to two people choosing exactly the same atoms from a 
20 choice of all the atoms in the Earth i.e. extremely unlikely. 

1 4.3 Quantum computer attack 

To break K, a quantum computer containing 160 qubits embedded in an appropriate algorithm must 
be built. As described in Section 5.7.1 .7 on page 648, an attack against a 160-bit key is not 
25 feasible. An outside estimate of the possibility of quantum computers is that 50 qubits may be 
achievable within 50 years. Even using a 50 qubit quantum computer, 2 110 tests are required to 
crack a 160 bit key. Assuming an array of 1 billion 50 qubit quantum computers, each able to try 2 50 
keys in 1 microsecond (beyond the current wildest estimates) finding the key would take an 
average of 18 billion years. 

30 

1 4.4 Ciphertext only attack 

An attacker can launch a ciphertext only attack on K by monitoring calls to Random and Read. 
However, given that all these calls also reveal the plaintext as well as the hashed form of the 
plaintext, the attack would be transformed into a stronger form of attack - a known plaintext attack. 

35 

14.5 Known pia\ ntext attack 
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It is easy to connect a logic analyzer to the connection between the System and the authentication 
chip, and thereby monitor the flow of data. This flow of data results in known plaintext and the 
hashed form of the plaintext, which can therefore be used to launch a known plaintext attack 
against K. 

5 To launch an attack against K, multiple calls to Random and Test must be made (with the call to 
Test being successful, and therefore requiring a call to Read on a valid chip). This is 
straightforward, requiring the attacker to have both a system authentication chip and a consumable 
authentication chip. For each set of calls, an X, S K [X] pair is revealed. The attacker must collect 
these pairs for further analysis. 
1 0 The question arises of how many pairs must be collected for a meaningful attack to be launched 
with this data. An example of an attack that requires collection of data for statistical analysis is 
differential cryptanalysis (see Section 14.13 on page 703). However, there are no known attacks 
against SHA-1 or HMAC-SHA1 [7][7][7], so there is no use for the collected data at this time. 

15 14.6 Chosen plaintext attacks 

The golden rule for the QA Chip is that it never signs something that is simply given to it - i.e. it 
never lets the user choose the message that is signed. 

Although the attacker can choose both R T and possibly M, ChipA advances its random number R A 
20 with each call to Read. The resultant message X therefore contains 160 bits of changing data each 
call that are not chosen by the attacker. 

To launch a chosen text attack the attacker would need to locate a chip whose R was the desired 
R. This makes the search effectively impossible. 

25 

1 4.7 Adaptive chosen plaintext attacks 

The HMAC construct provides security against all forms of chosen plaintext attacks [7]. This is 
primarily because the HMAC construct has 2 secret input variables (the result of the original hash, 
and the secret key). Thus finding collisions in the hash function itself when the input variable is 
30 secret is even harder than finding collisions in the plain hash function. This is because the former 
requires direct access to SHA-1 in order to generate pairs of input/output from SHA-1 . 

Since R changes with each call to Read, the user cannot choose the complete message. The only 
value that can be collected by an attacker is HMAC[R! | R 2 | MJ. These are not attacks against the 
35 SHA-1 hash function itself, and reduce the attack to a differential cryptanalysis attack (see Section 
14.13 on page 703), examining statistical differences between collected data. Given that there is no 
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differential cryptanalysis attack known against SHA-1 or HMAC, the protocols are resistant to the 
adaptive chosen plaintext attacks. 



14.8 Purposeful error attack 

5 An attacker can only launch a purposeful error attack on the Test function, since this is the only 
function in the Read protocol that validates input against the keys. 

With the Test function, a 0 value is produced if an error is found in the input - no further information 
is given. In addition, the time taken to produce the 0 result is independent of the input, giving the 
1 0 attacker no information about which bit(s) were wrong. 
A purposeful error attack is therefore fruitless. 

14.9 Chaining attack 

Any form of chaining attack assumes that the message to be hashed is over several blocks, or the 
1 5 input variables can somehow be set. The HMAC-SHA1 algorithm used by Protocol C1 only ever 
hashes one or two 512-bit blocks. Chaining attacks are not possible when only one block is used, 
and are extremely limited when two blocks are used. 

14.10 Birthday attack 

20 The strongest attack known against HMAC is the birthday attack, based on the frequency of 

collisions for the hash function [7][7]. However this is totally impractical for minimally reasonable 
hash functions such as SHA-1 . And the birthday attack is only possible when the attacker has 
control over the message that is hashed. 

Since in the protocols described for the QA Chip, the message to be signed is never chosen by the 
25 attacker (at least one 160-bit R value is chosen by the chip doing the signing), the attacker has no 
control over the message that is hashed. An attacker must instead search for a collision message 
that hashes to the same value (analogous to finding one person who shares your birthday). 

The clone chip must therefore attempt to find a new value R 2 such that the hash of R 1f R 2 and a 
30 chosen M 2 yields the same hash value as H[R 1 |R 2 |M]. However ChipT does not reveal the correct 
hash value (the Test function only returns 1 or 0 depending on whether the hash value is correct). 
Therefore the only way of finding out the correct hash value (in order to find a collision) is to 
interrogate a real ChipA. But to find the correct value means to update M, and since the decrement- 
only parts of M are one-way, and the read-only parts of M cannot be changed, a clone consumable 
35 would have to update a real consumable before attempting to find a collision. The alternative is a 
brute force attack search on the Test function to find a success (requiring each clone consumable 
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to have access to a System consumable). A brute force search, as described above, takes longer 
than the lifetime of the universe, in this case, per authentication. 

There is no point for a clone consumable to launch this kind of attack. 

5 

14.1 1 Substitution with a complete lookup table 

The random number seed in each System is 160 bits. The best case situation for an attacker is that 
no state data has been changed. Assuming also that the clone consumable does not advance its R, 
there is a constant value returned as M. A clone chip must therefore return S K [R | c] (where c is a 
1 0 constant), which is a 160 bit value. 

Assuming a 160-bit lookup of a 160-bit result, this requires 2.9 x 10 49 bytes, or 2.6 x 10 37 terabytes, 
certainly more space than is feasible for the near future. This of course does not even take into 
account the method of collecting the values for the ROM. A complete lookup table is therefore 
1 5 completely impossible. 

14.12 Substitution with a sparse lookup table 

A sparse lookup table is only feasible if the messages sent to the authentication chip are somehow 
predictable, rather than effectively random. 

20 

The random number R is seeded with an unknown random number, gathered from a naturally 
System authentication chip's Random function, and iterating some random event. There is no 
possibility for a clone manufacturer to know what the possible range of R is for all Systems, since 
each bit has an unrelated chance of being 1 or 0. 
25 Since the range of R in all systems is unknown, it is not possible to build a sparse lookup table that 
can be used in all systems. The general sparse lookup table is therefore not a possible attack. 

However, it is possible for a clone manufacturer to know what the range of R is for a given System. 
This can be accomplished by loading a LFSR with the current result from a call to a specific number 

30 of times into the future. If this is done, a special ROM can be built which will only contain the 
responses for that particular range of R, i.e. a ROM specifically for the consumables of that 
particular System. But the attacker still needs to place correct information in the ROM. The attacker 
will therefore need to find a valid authentication chip and call it for each of the values in R. 
Suppose the clone authentication chip reports a full consumable, and then allows a single use 

35 before simulating loss of connection and insertion of a new full consumable. The clone consumable 
would therefore need to contain responses for authentication of a full consumable and 
authentication of a partially used consumable. The worst case ROM contains entries for full and 
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partially used consumables for R over the lifetime of System. However, a valid authentication chip 
must be used to generate the information, and be partially used in the process. If a given System 
only produces n R-values, the sparse lookup-ROM required is 20n bytes (20 = 160/8) multiplied by 
the number of different values for M. The time taken to build the ROM depends on the amount of 
5 time enforced between calls to Read. 

After all this, the clone manufacturer must rely on the consumer returning for a refill, since the cost 
of building the ROM in the first place consumes a single consumable. The clone manufacturers 
business in such a situation is consequently in the refills. 

1 0 The time and cost then, depends on the size of R and the number of different values for M that 

must be incorporated in the lookup. In addition, a custom clone consumable ROM must be built to 
match each and every System, and a different valid authentication chip must be used for each 
System (in order to provide the full and partially used data). The use of an authentication chip in a 
System must therefore be examined to determine whether or not this kind of attack is worthwhile for 

15 a clone manufacturer. 

As an example, of a camera system that has about 10,000 prints in its lifetime. Assume it has a 
single Decrement Only value (number of prints remaining), and a delay of 1 second between calls 
to Read. In such a system, the sparse table will take about 3 hours to build, and consumes 100K. 
20 Remember that the construction of the ROM requires the consumption of a valid authentication 
chip, so any money charged must be worth more than a single consumable and the clone 
consumable combined. Thus it is not cost effective to perform this function for a single consumable 
(unless the clone consumable somehow contained the equivalent of multiple authentic 
consumables). 

25 

If a clone manufacturer is going to go to the trouble of building a custom ROM for each owner of a 
System, an easier approach would be to update System to completely ignore the authentication 
chip. 

30 Consequently, this attack is possible as a per-System attack, and a decision must be made about 
the chance of this occurring for a given System/Consumable combination. The chance will depend 
on the cost of the consumable and authentication chips, the longevity of the consumable, the profit 
margin on the consumable, the time taken to generate the ROM, the size of the resultant ROM, and 
whether customers will come back to the clone manufacturer for refills that use the same clone chip 

35 etc. 
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14.13 Differential cryptanalysis 

Existing differential attacks are heavily dependent on the structure of S boxes, as used in DES and 
other similar algorithms. Although HMAC-SHA1 has no S boxes, an attacker can undertake a 
differential-like attack by undertaking statistical analysis of: 
5 o Minimal-difference inputs, and their corresponding outputs 
o Minimal-difference outputs, and their corresponding inputs 

To launch an attack of this nature, sets of input/output pairs must be collected. The collection can 
be via known plaintext, or from a partially adaptive chosen plaintext attack. Obviously the latter, 
1 0 being chosen, will be more useful. 

Hashing algorithms in general are designed to be resistant to differential analysis. SHA-1 in 
particular has been specifically strengthened, especially by the 80 word expansion so that minimal 
differences in input will still produce outputs that vary in a larger number of bit positions (compared 
15 to 128 bit hash functions). In addition, the information collected is not a direct SHA-1 input/output 
set, due to the nature of the HMAC algorithm. The HMAC algorithm hashes a known value with an 
unknown value (the key), and the result of this hash is then rehashed with a separate unknown 
value. Since the attacker does not know the secret value, nor the result of the first hash, the inputs 
and outputs from SHA-1 are not known, making any differential attack extremely difficult. 

20 

There are no known differential attacks against SHA-1 or HMAC-SHA-1[56][56]. 

The following is a more detailed discussion of minimally different inputs and outputs from the QA 

Chip. 

25 14.13.1 Minimal difference inputs 

This is where an attacker takes a set of X, S K [X] values where the X values are minimally different, 
and examines the statistical differences between the outputs S K [X]. The attack relies on X values 
that only differ by a minimal number of bits. The question then arises as to how to obtain minimally 
different X values in order to compare the S K [X] values. 

30 

Although the attacker can choose both R T and possibly M, ChipA advances its random number R A 
with each call to Read. The resultant X therefore contains 160 bits of changing data each call, and 
is therefore not minimally different. 
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14.13.2 Minimal difference outputs 

This is where an attacker takes a set of X, S K [X] values where the S K [X] values are minimally 
different, and examines the statistical differences between the X values. The attack relies on S K [X] 
values that only differ by a minimal number of bits. 

5 

There is no way for an attacker to generate an X value for a given S K [X]. To do so would violate the 
fact that S is a one-way function (HMAC-SHA1 ). Consequently the only way for an attacker to 
mount an attack of this nature is to record all observed X, S K [X] pairs in a table. A search must then 
be made through the observed values for enough minimally different S K [X] values to undertake a 
1 0 statistical analysis of the X values. 

14.14 Message substitution attacks 

In order for this kind of attack to be carried out, a clone consumable must contain a real 
authentication chip, but one that is effectively reusable since it never gets decremented. The clone 
1 5 authentication chip would intercept messages, and substitute its own. However this attack does not 
give success to the attacker. 

A clone authentication chip may choose not to pass on a Write command to the real authentication 
chip. However the subsequent Read command must return the correct response (as if the Write 
20 had succeeded). To return the correct response, the hash value must be known for the specific R 
and M. An attacker can only determine the hash value by actually updating M in a real Chip, which 
the attacker does not want to do. Even changing the R sent by System does not help since the 
System authentication chip must match the R during a subsequent Test. 

25 A message substitution attack would therefore be unsuccessful. This is only true if System updates 
the amount of consumable remaining before it is used. 

1 4.1 5 Reverse engineering the key generator 

If a pseudo-random number generator is used to generate keys, there is the potential for a clone 
30 manufacture to obtain the generator program or to deduce the random seed used. This was the 
way in which the security layer of the Netscape browser was initially broken [33]. 

14.16 Bypassing the authentication process 

The System should ideally update the consumable state data before the consumable is used, and 
35 follow every write by a read (to authenticate the write). Thus each use of the consumable requires 
an authentication. If the System adheres to these two simple rules, a clone manufacturer will have 
to simulate authentication via a method above (such as sparse ROM lookup). 
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14.17 Reuse of authentication chips 

Each use of the consumable requires an authentication. If a consumable has been used up, then its 
authentication chip will have had the appropriate state-data values decremented to 0. The chip can 
5 therefore not be used in another consumable. 

Note that this only holds true for authentication chips that hold Decrement-Only data items. If there 
is no state data decremented with each usage, there is nothing stopping the reuse of the chip. This 
is the basic difference between Presence-Only authentication and Consumable Lifetime 
1 0 authentication. All described protocols allow both. 

The bottom line is that if a consumable has Decrement Only data items that are used by the 
System, the authentication chip cannot be reused without being completely reprogrammed by a 
valid programming station that has knowledge of the secret key (e.g. an authorized refill station). 

15 

1 4.1 8 Management decision to omit authentication to save costs 

Although not strictly an external attack, a decision to omit authentication in future Systems in order 
to save costs will have widely varying effects on different markets. 

20 In the case of high volume consumables, it is essential to remember that it is very difficult to 
introduce authentication after the market has started, as systems requiring authenticated 
consumables will not work with older consumables still in circulation. Likewise, it is impractical to 
discontinue authentication at any stage, as older Systems will not work with the new, 
unauthenticated, consumables. In the second case, older Systems can be individually altered by 

25 replacing the System program code. 

Without any form of protection, illegal cloning of high volume consumables is almost certain. 
However, with the patent and copyright protection, the probability of illegal cloning may be, say 
50%. However, this is not the only loss possible. If a clone manufacturer were to introduce clone 
30 consumables which caused damage to the System (e.g. clogged nozzles in a printer due to poor 
quality ink), then the loss in market acceptance, and the expense of warranty repairs, may be 
significant. 

In the case of a specialized pairing, such as a car/car-keys, or door/door-key, or some other similar 
35 situation, the omission of authentication in future systems is trivial and without repercussions. This 
is because the consumer is sold the entire set of System and Consumable authentication chips at 
the one time. 
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1 4.19 Garrote/bribe attack 

If humans do not know the key, there is no amount of force or bribery that can reveal them. The use 
of ChipF and the ReplaceKey protocol is specifically designed to avoid the requirement of the 
programming station having to know the new key. However ChipF must be told the new key at 
5 some stage, and therefore it is the person(s) who enter the new key into ChipF that are at risk. 

The level of security against this kind of attack is ultimately a decision for the System/Consumable 
owner, to be made according to the desired level of service. 

1 0 For example, a car company may wish to keep a record of all keys manufactured, so that a person 
can request a new key to be made for their car. However this allows the potential compromise of 
the entire key database, allowing an attacker to make keys for any of the manufacturer's existing 
cars. It does not allow an attacker to make keys for any new cars. Of course, the key database itself 
may also be encrypted with a further key that requires a certain number of people to combine their 

1 5 key portions together for access. If no record is kept of which key is used in a particular car, there is 
no way to make additional keys should one become lost. Thus an owner will have to replace his 
car's authentication chip and all his car-keys. This is not necessarily a bad situation. 

By contrast, in a consumable such as a printer ink cartridge, the one key combination is used for ail 
20 Systems and all consumables. Certainly if no backup of the keys is kept, there is no human with 
knowledge of the key, and therefore no attack is possible. However, a no-backup situation is not 
desirable for a consumable such as ink cartridges, since if the key is lost no more consumables can 
be made. The manufacturer should therefore keep a backup of the key information in several parts, 
where a certain number of people must together combine their portions to reveal the full key 
25 information. This may be required if case the chip programming station needs to be reloaded. 

In any case, none of these attacks are against the authenticated read protocol, since no humans 
are involved in the authentication process. 

30 Logical Interface 

15 Introduction 

The QA Chip has a physical and a logical external interface. The physical interface defines how the 
OA Chip can be connected to a physical System, while the logical interface determines how that 
System can communicate with the QA Chip. This section deals with the logical interface. 

35 

15.1 Operating Modes 

The QA Chip has four operating modes - idle Mode, Program Mode, Trim Mode and Active Mode. 
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o Idle Mode is used to allow the chip to wait for the next instruction from the System. 

o Trim Mode is used to determine the clock speed of the chip and to trim the frequency during 

the initial programming stage of the chip (when Flash memory is garbage). The clock 

frequency must be trimmed via Trim Mode before Program Mode is used to store the 
5 program code. 

o Program Mode is used to load up the operating program code, and is required because the 

operating program code is stored in Flash memory instead of ROM (for security reasons), 
o Active Mode is used to execute the specific authentication command specified by the 

System. Program code is executed in Active Mode. When the results of the command have 
1 0 been returned to the System, the chip enters Idle Mode to wait for the next instruction. 



15.1.1 Idle Mode 

The OA Chip starts up in Idle Mode. When the Chip is in Idle Mode, it waits for a command from the 
master by watching the primary id on the serial line. 
15 o |f the primary id matches the global id (0x00, common to all QA Chips), and the following 
byte from the master is the Trim Mode id byte, the QA Chip enters Trim Mode and starts 
counting the number of internal clock cycles until the next byte is received. 
© If the primary id matches the global id (0x00, common to all QA Chips), and the following 
byte from the master is the Program Mode id byte, the QA Chip enters Program Mode. 
20 o |f the primary id matches the global id (0x00, common to all QA Chips), and the following 
byte from the master is the Active Mode id byte, the QA Chip enters Active Mode and 
executes startup code, allowing the chip to set itself into a state to receive authentication 
commands (includes setting a local id). 
° If the primary id matches the chip's local id, and the following byte is a valid command code, 
25 the QA Chip enters Active Mode, allowing the command to be executed. 

The valid 8-bit serial mode values sent after a global id are as shown in Table 238. They are 
specified to minimize the chances of them occurring by error after a global id (e.g. OxFF and 0x00 are 
not used): 

30 Table 238. Id byte values to place chip in specific mode 



Value 


Interpretation 


10100101 (0xA5) 


Trim Mode 


100011 10 (0x8E) 


Program Mode 


01111000 (0x78) 


Active Mode 
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15.1.2 Trim Mode 

Trim Mode is enabled by sending a global id byte (0x00) followed by the Trim Mode command byte. 
The purpose of Trim Mode is to set the trim value (an internal register setting) of the internal ring 
oscillator so that Flash erasures and writes are of the correct duration. This is necessary due to the 
5 variation of the clock speed due to process variations. If writes an erasures are too long, the Flash 
memory will wear out faster than desired, and in some cases can even be damaged. 
Trim Mode works by measuring the number of system clock cycles that occur inside the chip from 
the receipt of the Trim Mode command byte until the receipt of a data byte. When the data byte is 
received, the data byte is copied to the trim register and the current value of the count is transmitted 
10 to the outside world. 

Once the count has been transmitted, the OA Chip returns to Idle Mode. 

At reset, the internal trim register setting is set to a known value r. The external user can now 
1 5 perform the following operations: 

o send the global id+write followed by the Trim Mode command byte 
o send the 8-bit value v over a specified time t 
o send a stop bit to signify no more data 

o send the global id+read followed by the Trim Mode command byte 
20 o receive the count c 

o send a stop bit to signify no more data 

At the end of this procedure, the trim register will be v, and the external user will know the 
relationship between external time t and internal time c. Therefore a new value for v can be 
25 calculated. 

The Trim Mode procedure can be repeated a number of times, varying both t and v in known ways, 
measuring the resultant c. At the end of the process, the final value for v is established (and stored 
in the trim register for subsequent use in Program Mode). This value v must also be written to the 
30 flash for later use (every time the chip is placed in Active Mode for the first time after power-up). 

15.1.3 Program Mode 

Program Mode is enabled by sending a global id byte (0x00) followed by the Program Mode 
command byte. 

35 

The OA Chip determines whether or not the internal fuse has been blown (by reading 32-bit word 0 
of the information block of flash memory). 
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If the fuse has been blown the Program Mode command is ignored, and the QA Chip returns to Idle 
Mode. 

If the fuse is still intact, the chip enters Program Mode and erases the entire contents of Flash 
5 memory. The QA Chip then validates the erasure. If the erasure was successful, the QA Chip 
receives up to 4096 bytes of data corresponding to the new program code and variable data. The 
bytes are transferred in order byte 0 to byte^gs- 

Once all bytes of data have been loaded into Flash, the QA Chip returns to Idle Mode. 

10 

Note that Trim Mode functionality must be performed before a chip enters Program Mode for the 
first time. 

Once the desired number of bytes have been downloaded in Program Mode, the LSS Master must 
1 5 wait for 80jis (the time taken to write two bytes to flash at nybble rates) before sending the new 
transaction (eg Active Mode). Otherwise the last nybbles may not be written to flash. 

15.1.4 Active Mode 

Active Mode is entered either by receiving a global id byte (0x00) followed by the Active Mode 
20 command byte, or by sending a local id byte followed by a command opcode byte and an 

appropriate number of data bytes representing the required input parameters for that opcode. 

In both cases, Active Mode causes execution of program code previously stored in the flash 
memory via Program Mode. As a result, we never enter Active Mode after Trim Mode, without a 
25 Program Mode in between. However once programmed via Program Mode, a chip is allowed to 
enter Active Mode after power-up, since valid data will be in flash. 

If Active Mode is entered by the global id mechanism, the QA Chip executes specific reset startup 
code, typically setting up the local id and other IO specific data. 

30 

If Active Mode is entered by the local id mechanism, the QA Chip executes specific code depending 
on the following byte, which functions as an opcode. The opcode command byte format is shown in 
Table 239: 

Table 239. Command byte 

35 



bits 


Description 


2-0 


Opcode 
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5-3 


-.opcode 


7-6 


count of number of bits set in opcode (0 to 3) 



The interpretation of the 3-bit opcode is shown in Table 240: 
Table 240. OA Chip opcodes 



Op* 


Mn J 


Description 


000 


RST 


Reset 


001 


RND 


Random 


010 


RDM 


Read M 


011 


TST 


Test 


100 


WRM 


Write M with no authentication 


101 


WRA 


Write with Authentication (to M, P, or K) 


110 


chip specific - reserved for ChipF, ChipS etc 


111 


chip specific - reserved for ChipF, ChipS etc 



The command byte is designed to ensure that errors in transmission are detected. 
Regular QA Chip commands are therefore comprised of an opcode plus any associated 
parameters. The commands are listed in Table 241 : 
Table 241 . QA Chip commands 

10 



Command 


Input 
opcode 


Additional parms 


Output 
Return value 


Reset 


RST 






Random 


RND 




[20] 


Read 


RDM 


[1.1.20] 


[20, 64, 20] 4 


Test 


TST 


[1,20,64,20] j 


89* if successful, 76 if 
not 


Write 


WRM 


[1,64, 20] 


89 if successful, 76 if not 



Opcode 
Mnemonic 

[n, m] = list of parameters where n bytes for first parameter, and m bytes for the second etc. 

n = actual byte pattern required (in hex). The bytes 0x76 and 0x89 were chosen as the bool ean values 0 and 1 as 
they are inverses of each other, and should not be generated acciden tally. 
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WWritoAi ith 


VA/D A 
VV KM 


yes. ron GA om 


oy rr successiui, /o rr not 


r\.epicicer\ey 


VA/D A 
VV rvM 


qq m on on om 

cjy /o [i, zu, ^u, zuj 


oy rr successful, / o rr not 


SetPerm issions 


WRA 


RQ ftQ fl 1 90 4 201 


r4i 


SignM* 


ChipS only 


[1, 20, 20, 64, 20, 64] 


[20, 64, 20] 


SignP' 


ChipS only 


[1,20, 20, 4, 20, 4] 


[20, 64, 20] 


GetProgKey 


ChipF only 


[1,20] 


[20, 20, 20] 


SetPartialKey 


ChipF only 


[1.4] 


89 if successful, 76 if not 



Apart from the Reset command, the next four commands are the commands most likely to be used 
during regular operation. The next three commands are used to provide authenticated writes (which 
are expected to be uncommon). The final set of commands (including SignM), are expected to be 
5 specially implemented on ChipS and ChipF QA Chips only. 

The input parameters are sent in the specified order, with each parameter being sent least 
significant byte first and most significant byte last. 

Return (output) values are read in the same way - least significant byte first and most significant 
byte last. The client must know how many bytes to retrieve. The QA Chip will time out and return to 

1 0 Idle Mode if an incorrect number of bytes is provided or read. 

In most cases, the output bytes from one chip's command (the return values) can be fed directly as 
the input bytes to another chip's command. An example of this is the RND and RD commands. The 
output data from a call to RND on a trusted QA Chip does not have to be kept by the System. 
Instead, the System can transfer the output bytes directly to the input of the non-trusted QA Chip's 

1 5 RD command. The description of each command points out where this is so. 

Each of the commands is examined in detail in the subsequent sections. Note that some algorithms 
are specifically designed because flash memory is assumed for the implementation of non-volatile 
variables. 

15.1.5 Non volatile variables 
20 The memory within the QA Chip contains some non-volatile (Flash) memory to store the variables 
required by the authentication protocol. Table 242 summarizes the variables. 

Table 242. Non volatile variables required by the authentication protocol 



Name 



Size 



£ 



escription 



It is expected that most QA Chips will implement SignM as a function that returns 0x00. Only a limited number of 
chips will be programmed to allow SignM functionality. It is included here as an example of how signatures can be 
generated for authenticated writes. 

It is expected that most QA Chips will implement SignP as a function that returns 0x00. Only a limited number of chips 
will be programmed to allow SignP functionality. It is included here as an example of how signatures can be 
generated for authenticated writes. 
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(bits) 




N 


8 


Number of keys known to the chip 


T 


8 


Number of vectors M is broken into 


K n 

Rk 


160 per key, 
160 for R K 


Array of N secret keys used for calculating F Kn [X] 
where K„ is the nth element of the array. Each Kn 
must not be stored directly in the OA Chip. Instead, 
each chip needs to store a single random number 
R K (different for each chip), Kn©R K , and -iKn0R K . 
The stored Kn0R K can be XORed with R K to obtain 
the real K n . Although -iK n ©R|< must be stored to 
protect against differential attacks, it is not used. 


R 


160 


Current random number used to ensure time 
varying messages. Each chip instance must be 
seeded with a different initial value. Changes for 
each signature generation. 


M T 


512 per M 


Array of T memory vectors. Only M 0 can be written 
to with an authorized write, while all Ms can be 
written to in an unauthorized write. Writes to M 0 are 
optimized for Flash usage, while updates to any 
other M n are expensive with regards to Flash 
utilization, and are expected to be only performed 
once per section of M n . M-i contains T and N in 
Readonly form so users of the chip can know 
these two values. 


Pt+n 


32 per P 


T+N element array of access permissions for each 
part of M. Entries n={0... T-1} hold access 
permissions for non-authenticated writes to M n (no 
key required). Entries n={T to T+N-1}hold access 
permissions for authenticated writes to M 0 for K„. 
Permission choices for each part of M are Read 
Only, Read/Write, and Decrement Only 


MinTicks 


32 


The minimum number of clock ticks between calls 
to key-based functions. 



Note that since these variables are in Flash memory, writes should be minimized. The it is not a 
simple matter to write a new value to replace the old. Care must be taken with flash endurance, and 
speed of access. This has an effect on the algorithms used to change Flash memory based 
registers. For example, Flash memory should not be used as a shift register. 
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A reset of the OA Chip has no effect on the non-volatile variables. 
15.1.5.1 MandP 

M n contains application specific state data, such as serial numbers, batch numbers, and amount of 
5 consumable remaining. M n can be read using the Read command and written to via the Write and 
WriteA commands. 

M 0 is expected to be updated frequently, while each part of M 1H1 should only be written to once. 
Only M 0 can be written to via the WriteA command. 

10 

Mi contains the operating parameters of the chip as shown in Table 243, and M 2 -n are application 
specific. 

Table 243. Interpretation of 



Length 


Bits 


interpretation 


8 


7-0 


Number of available keys 


8 


15-8 


Number of available M vectors 


16 


31-16 


Revision of chip 


96 


127-32 


Manufacture id information 


128 


255-128 


Serial number 


8 


263-256 


Local id of chip 


248 


511-264 


reserved 



15 

Each Mn is 512 bits in length, and is interpreted as a set of 16 x 32-bit words. Although M n may 
contain a number of different elements, each 32-bit word differs only in write permissions. Each 32- 
bit word can always be read. Once in client memory, the 512 bits can be interpreted in anyway 
chosen by the client. The different write permissions for each P are outlined in Table 244: 
20 Table 244. Write permissions 



Data type 


permission description 


Read Only 


Can never be written to 


ReadWrite 


Can always be written to 


Decrement Only 


Can only be written to if the new value is less than the old 
value. Decrement Only values can be any multiple of 32 bits. 



To accomplish the protection required for writing, a 2-bit permission value P is defined for each of 
the 32-bit words. Table 245 defines the interpretation of the 2-bit permission bit-pattern: 
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Table 245. Permission bit interpretation 



Bits 


Op 


Interpretation 


Action taken during Write command 


00 


RW 


ReadWrite 


The new 32-bit value is always written to 
M[n]. 


01 


MSR 


Decrement Only 
(Most Significant 
Region) 


The new 32-bit value is only written to 
M[n] if it is less than the value currently 
in M[n]. This is used for access to the 
Most Significant 16 bits of a Decrement 
Only number. 


10 


NMSR 


Decrement Only 
(Not the Most 
Significant Region) 


The new 32-bit value is only written to 
M[n] if M[n-1] could also be written. The 
NMSR access mode allows multiple 
precision values of 32 bits and more ! 
(multiples of 32 bits) to decrement. 


11 


RO 


Read Only 


The new 32-bit value is ignored. 
M[n] is left unchanged. 



The 16 sets of permission bits for each 512 bits of M are gathered together in a single 32-bit 
5 variable P, where bits 2n and 2n+1 of P correspond to word n of M as follows: 

Each 2-bit value is stored as a pair with the msb in bit 1 , and the Isb in bit 0. Consequently, if words 
0 to 5 of M had permission MSR, with words 6-15 of M permission RO, the 32-bit P variable would 

be 0XFFFFF555: 

10 

11-11-11-11-11-11-11-11-11-11 -01 -01-01-01-01-01 

During execution of a Write and WriteA command, the appropriate Permissions[n] is examined for 
each M[n] starting from n=15 (msw of M) to n=0 (Isw of M), and a decision made as to whether the 
1 5 new M[n] value will replace the old. Note that it is important to process the M[n] from msw to Isw to 
correctly interpret the access permissions. 

Permissions are set and read using the OA Chip's SetPermissions command. The default for P is all 
0s (RW) with the exception of certain parts of Mi. 

20 

Note that the Decrement Only comparison is unsigned, so any Decrement Only values that require 
negative ranges must be shifted into a positive range. For example, a consumable with a 
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Decrement Only data item range of -50 to 50 must have the range shifted to be 0 to 100. The 
System must then interpret the range 0 to 100 as being -50 to 50. Note that most instances of 
Decrement Only ranges are N to 0, so there is no range shift required. 

5 For Decrement Only data items, arrange the data in order from most significant to least significant 
32-bit quantities from M[n] onward. The access mode for the most significant 32 bits (stored in M[n]) 
should be set to MSR. The remaining 32-bit entries for the data should have their permissions set 
to NMSR. 

10 If erroneously set to NMSR, with no associated MSR region, each NMSR region will be considered 
independently instead of being a multi-precision comparison. 

Examples of allocating M and Permission bits can be found in [86]. 

15 15.1.5.2 KandR K 

K is the 1 60-bit secret key used to protect M and to ensure that the contents of M are valid (when M 
is read from a non trusted chip). K is initially programmed after manufacture, and from that point on, 
K can only be updated to a new value if the old K is known. Since K must be kept secret, there is no 
command to directly read it. 

20 

K is used in the keyed one-way hash function HMAC-SHA1 . As such it should be programmed with 
a physically generated random number, gathered from a physically random phenomenon. Kmust 
NOT be generated with a computer-run random number generator. The security of the OA Chips 
depends on K being generated in a way that is not deterministic. 

25 

Each Kn must not be stored directly in the OA Chip. Instead, each chip needs to store a single 
random number Rk (different for each chip), K n 0R K , and -nKn0R K . The stored K 0 ©Rk can be 
XORed with R K to obtain the real K n . Although -.Kn©R K must be stored to protect against differential 
attacks, it is not used. 

30 

15.1.5.3 R 

R is a 160-bit random number seed that is set up after manufacture (when the chip is programmed) 
and from that point on, cannot be changed. R is used to ensure that each signed item contains time 
varying information (not chosen by an attacker), and each chip's R is unrelated from one chip to the 
35 next. 
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R is used during the Test command to ensure that the R from the previous call to Random was used 
as the session key in generating the signature during Read. Likewise, R is used during the 
WriteAuth command to ensure that the R from the previous call to Read was used as the session 
key during generation of the signature in the remote Authenticated chip. 

5 

The only invalid value for R is 0. This is because R is changed via a 160-bit maximal period LFSR 
(Linear Feedback Shift Register) with taps on bits 0, 2, 3, and 5, and is changed only by a 
successful call to a signature generating function (e.g. Test, WriteAuth). 

1 0 The logical security of the OA Chip relies not only upon the randomness of K and the strength of the 
HMAC-SHA1 algorithm. To prevent an attacker from building a sparse lookup table, the security of 
the OA Chip also depends on the range of R over the lifetime of all Systems. What this means is 
that an attacker must not be able to deduce what values of R there are in produced and future 
Systems. Ideally, R should be programmed with a physically generated random number, gathered 

1 5 from a physically random phenomenon (must not be deterministic). R must NOT be generated with 
a computer-run random number generator. 

15.1.5.4 MinTicks 

There are two mechanisms for preventing an attacker from generating multiple calls to key-based 
20 functions in a short period of time. The first is an internal ring oscillator that is temperature-filtered. 
The second mechanism is the 32-bit MinTicks variable, which is used to specify the minimum 
number of QA Chip clock ticks that must elapse between calls to key-based functions. 

The MinTicks variable is set to a fixed value when the QA Chip is programmed. It could possibly be 
25 stored in 

The effective value of MinTicks depends on the operating clock speed and the notion of what 
constitutes a reasonable time between key-based function calls (application specific). The duration 
of a single tick depends on the operating clock speed. This is the fastest speed of the ring oscillator 
30 generated clock (i.e. at the lowest valid operating temperature). 

Once the duration of a tick is known, the MinTicks value can to be set. The value for MinTicks will be 
the minimum number of ticks required to pass between calls to the key-based functions (there is no 
need to protect Random as this produces the same output each time it is called multiple times in a 
35 row). The value is a real-time number, and divided by the length of an operating tick. 
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It should be noted that the MinTicks variable only slows down an attacker and causes the attack to 
cost more since it does not stop an attacker using multiple System chips in parallel. 

1 5.1 .6 GetProgramKey 
5 Input: n, Re = [1 byte, 20 bytes] 

Output: Rl, EKkPKnIRElRLlCaD. SKx[R L |EKx[SKn[F^|FUC 3 ]|Cd = [20, 20, 20] 

Changes: Rl 

Note: The GetProgramKey command is only implemented in ChipF, and not in all QA Chips. 
The GetProgramKey command is used to produce the bytestream required for updating a specified 
1 0 key in ChipP. Only an QA Chip programmed with the correct values of the old Kn can respond 

correctly to the GetProgramKey request. The output bytestream from the Random command can 
be fed as the input bytestream to the ReplaceKey command on the QA Chip being programmed 
(ChipP). 

1 5 The input bytestream consists of the appropriate opcode followed by the desired key to generate 
the signature, followed by 20 bytes of ^(representing the random number read in from ChipP). 

The local random number Rl is advanced, and signed in combination with Re and C 3 by the chosen 
key to generate a time varying secret number known to both ChipF and ChipP. This signature is 
20 then XORed with the new key K x (this encrypts the new key). The first two output parameters are 
signed with the old key to ensure that ChipP knows it decoded K x correctly. 

This whole procedure should only be allowed a given number of times. The actual number can 
conveniently be stored in the local Mo[0] (eg word 0 of Mo) with Readonly permission. Of course 
25 another chip could perform an Authorised write to update the number (via a ChipS) should it be 
desired. 

The GetProgramKey command is implemented by the following steps: 

Loop through all of Flash, reading each word (will trigger checks) 
30 Accept n 

Restrict n to N 

Accept R E 

If (M 0 [0J = 0) 

Output 60 bytes of 0x00 # no more keys allowed to be generated 
35 from this chipF 

Done 
Endlf 
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Advance R L 

SIG <- Skii[Rl|Re| C 3 ] # calculation must take constant time 
Tmp <- SIG 0 K x 
5 Output R L 

Output Tmp 

Decrement M 0 [0] # reduce the number of allowable key 

generations by 1 

SIG <- Skx [Rl| Tmp | C 3 ] # calculation must take constant time 
10 Output SIG 

15.1.7 Random 

Input: None 
Output: R L = [20 bytes] 
Changes: None 

1 5 The Random command is used by a client to obtain an input for use in a subsequent authentication 
procedure. Since the Random command requires no input parameters, it is therefore simply 1 byte 
containing the RND opcode. 

The output of the Random command from a trusted OA Chip can be fed straight into the non- 
20 trusted chip's Read command as part of the input parameters. There is no need for the client to 

store them at all, since they are not required again. However the Test command will only succeed if 
the data passed to the Read command was obtained first from the Random command. 

If a caller only calls the Random function multiple times, the same output will be returned each time. 
25 R will only advance to the next random number in the sequence after a successful call to a function 
that returns or tests a signature (e.g. Test, see Section 15.1 .13 on page 725 for more information). 

The Random command is implemented by the following steps: 

Loop through all of Flash, reading each word (will trigger checks) 
30 Output R L 

15.1.8 Read 

Input: n, t, R E = [1 byte, 1 byte, 20 bytes] 

Output: Rl, M|_tf S K n[RE|RiJCi|M Lt ] = [20 bytes, 64 bytes, 20 bytes] 

35 Changes: R|_ 

The Read command is used to read the entire state data (Mt) from an OA Chip. Only an OA Chip 
programmed with the correct value of Kn can respond correctly to the Read request. The output 
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bytes tream from the Read command can be fed as the input bytestream to the Test command on a 
trusted OA Chip for verification, with Mt stored for later use if Test returns success. 

The input bytestream consists of the RD opcode followed by the key number to use for the 
5 signature, which M to read, and the bytes 0-19 of Re. 23 bytes are transferred in total. Re is obtained 
by calling the trusted QA Chip's Random command. The 20 bytes output by the trusted chip's 
Random command can therefore be fed directly into the non-trusted chip's Read command, with no 
need for these bits to be stored by System. 

1 0 Calls to Read must wait for MinTicksRemaining to reach 0 to ensure that a minimum time will elapse 
between calls to Read. 

The output values are calculated, MinTicksRemaining is updated, and the signature is returned. The 
contents of Mu are transferred least significant byte to most significant byte. The signature 
1 5 SKn[RE|Ri|Ci|Mu] must be calculated in constant time. 

The next random number is generated from R using a 160-bit maximal period LFSR (tap selections 
on bits 5, 3, 2, and 0). The initial 160-bit value for R is set up when the chip is programmed, and can 
be any random number except 0 (an LFSR filled with 0s will produce a never-ending stream of 0s). 
20 R is transformed by XORing bits 0, 2, 3, and 5 together, and shifting all 160 bits right 1 bit using the 
XOR result as the input bit to b i5 9- The process is shown in Figure 347 below. 

Care should be taken when updating R since it lives in Flash. Program code must assume power 
could be removed at any time. 



The Read command is implemented with the following steps: 
Wait for MinTicksRemaining to become 0 

Loop through all of Flash, reading each word (will trigger checks) 
Accept n 



25 



30 



Accept t 



Restrict n 



to N 



Restrict t 



to T 



Accept R E 



Advance R L 



35 



Output R L 
Output M LC 

Sig <- SKntRElRiJCilMLt] # calculation must take constant time 
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MinTicksRemaining <— MinTicks 
Output Sig 

Wait for MinTicksRemaining to become 0 

5 15.1.9 Set Permissions 

Input: n, p, Re, P E , SIG E = [1 byte, 1 byte, 20 bytes, 4 bytes, 20 bytes] 

Output: P p 
Changes: P p> R L 

1 0 The SetPermissions command is used to securely update the contents of P P (containing OA Chip 
permissions). The WriteAuth command only attempts to replace P P if the new value is signed 
combined with our local R. 

It is only possible to sign messages by knowing Kn. This can be achieved by a call to the SignP 
1 5 command (because only a ChipS can know Kn). It means that without a chip that can be used to 
produce the required signature, a write of any value to P P is not possible. 

The process is very similar to Test, except that if the validation succeeds, the Pe input parameter is 
additionally ORed with the current value for Pp. Note that this is an OR, and not a replace. Since the 
20 SetParms command only sets bits in P P , the effect is to allow the permission bits corresponding to 
M[n] to progress from RW to either MSR, NMSR, or RO. 

The SetPermissions command is implemented with the following steps: 
Wait for MinTicksRemaining to become 0 
25 Loop through all of Flash, reading each word (will trigger checks) 

Accept n 
Restrict n to N 
Accept p 
30 Restrict p to T+N 

Accept R E 
Accept P E 

SIG L <— Srji [R l I R E | P E | C 2 ] # calculation must take constant time 
Accept SIGb 
35 If (SIGe = SIG L ) 

Update R L 
P P P P v P E 
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Endlf 

Output P P # success or failure will be determined by receiver 
MinTicksRemaining «- MinTicks 

15.1.10 ReplaceKey 

5 Input: n, Re, V, SIGe = [ 1 byte, 20 bytes, 20 bytes, 20 bytes] 

Output: Boolean (0x76=failure, 0x89 = success) 
Changes: Kn, Ml, Rl 

The ReplaceKey command is used to replace the specified key in the OA Chip flash memory. 
However Kn can only be replaced if the previous value is known. A return byte of 0x89 is produced if 
1 0 the key was successfully updated, while 0x76 is returned for failure. 

A ReplaceKey command consists of the WRA command opcode followed by 0x89, 0x76, and then 
the appropriate parameters. Note that the new key is not sent in the clear, it is sent encrypted with 
the signature of Rl, Re and C 3 (signed with the old key). The first two input parameters must be 
1 5 verified by generating a signature using the old key. 

The ReplaceKey command is implemented with the following steps: 

Loop through all of Flash, reading each word (will trigger checks) 
Accept n 
20 Restrict n to N 

Accept R E # session key from ChipF 
Accept V # encrypted key 

SIG L <- S^CRe-IvIc^] # calculation must take constant time 
25 Accept SIGe 

If (SIG L = SIGe 2 ) # comparison must take constant time 

SIG L <— Sjcn [R L | Re I C 3 ] # calculation must take constant time 

Advance R L 

K E <- SIG L 0 V 

30 Kn <- K E # involves storing (K E © R K ) and (— «K E 0 

R K ) 

Output 0x89 # success 
Else 

Output 0x76 # failure 
35 Endlf 

15.1.11 SignM 

Input: n.Rx.RE.ME.SIGE.Mdesired = [1 byte, 20 bytes, 20 bytes, 64 bytes,32 bytes] 
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Output: Rl, Mnew, Skt»[Re I Rl I Ci| Mnew] = [20 bytes, 64 bytes, 20 bytes] 
Changes: Rl 

Note: The SignM command is only implemented in ChipS, and not in all QA Chips. 
The SignM command is used to produce a valid signed M for use in an authenticated write 
5 transaction. Only an QA Chip programmed with correct value of K« can respond correctly to the 
SignM request. The output bytestream from the SignM command can be fed as the input 
bytestream to the WriteA command on a different QA Chip. 

The input bytestream consists of the SMR opcode followed by 1 byte containing the key number to 
use for generating the signature, 20 bytes of Rx (representing the number passed in as R to ChipU's 
1 0 READ command, i.e. typically 0), the output from the READ command (namely Re, Me, and SIGe), 
and finally the desired M to write to ChipU. 

The SignM command only succeeds when SIGe = Sk[Rx | Re | Ci| Me], indicating that the request was 
generated from a chip that knows K. This generation and comparison must take the same amount of 
time regardless of whether the input parameters are correct or not. If the times are not the same, an 
1 5 attacker can gain information about which bits of the supplied signature are incorrect. If the 
signatures match, then Rl is updated to be the next random number in the sequence. 

Since the SignM function generates signatures, the function must wait for the MinTicksRemaining 
register to reach 0 before processing takes place. 

20 

Once all the inputs have been verified, a new memory vector is produced by applying a specially 
stored P value (eg word 1 of Mo) and Mdesired against Me. Effectively, it is performing a regular Write, 
but with separate P against someone else's M. The Mnew is signed with an updated Rl (and the 
passed in Re), and all three values are output (the random number Rl, Mnew, and the signature). The 
25 time taken to generate this signature must be the same regardless of the inputs. 

Typically, the SignM command will be acting as a form of consumable command, so that a given 
ChipS can only generate a given number of signatures. The actual number can conveniently be 
stored in Mo (eg word 0 of Mo) with Readonly permissions. Of course another chip could perform an 
30 Authorised write to update the number (using another ChipS) should it be desired. 

The SignM command is implemented with the following steps: 
Wait for MinTicksRemaining to become 0 

Loop through all of Flash, reading each word (will trigger checks) 

35 

Accept n 
Restrict n to N 
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Accept R x # don' t care what this number is 

Accept R E 
Accept M E 

SIG L <- [R x | R E | Ci | M E ] # calculation must take constant time 
Accept SIG E 

Accept Mdesired 

If (<SIG E * SIG L ) OR (M L [03 =0)) # fail if bad signature or 
allowed sigs = 0 

Output appropriate number of 0 # report failure 

Done 
Endlf 

Update R L 

# Create the new version of M in ram from W and Permissions 

# This is the same as the core process of Write function 

# except that we don't write the results back to M 
DecEncountered <— 0 

EqEncountered <— 0 

Permissions = M L [1] # assuming 

contains appropriate permissions 
For n <— msw to Isw # (word 15 to 0) 
AM <— Permissions [n] 

LT <r- (Mdesired [n] < M E [n] ) # comparison is unsigned 
EQ <r- (Mdesired tn] = M E [n] ) 

WE <- (AM = RW) V ( (AM = MSR) A LT) v ( (AM = NMSR) 
(DecEncountered v LT) ) 

DecEncountered <— ( (AM = MSR) a LT) 

v ( (AM = NMSR) a DecEncountered) 
v ( (AM = NMSR) a EqEncountered a LT) 
EqEncountered <— ( (AM = MSR) a EQ) v ( (AM = NMSR) 
EqEncountered a EQ) 

If (-.WE) A (M E [n] ^ Mdesired [n] ) 

Output appropriate number of 0 # report failure 

Endlf 
EndFor 
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# At this point, M^ired is correct 
Output R L 

Output Mdesired # Mdesired is now effectively M new 

5 Sig SKntRElRLlCilMdesiredl # calculation must take constant time 

MinTicksRemaining <— MinTicks 

Decrement M L [0] # reduce the number of allowable signatures by 

1 

Output Sig 
10 15.1.12 SignP 

Input: n.RE.Pdesired = [1 byte, 20 bytes, 4 bytes] 

Output: Rl, S Kn [RE | Rl | Pd«nd|C2] = [20 bytes, 20 bytes] 
Changes: Rl 

Note: The SignP command is oniy implemented in ChipS, and not in ail QA Chips. 

15 

The SignP command is used to produce a valid signed P for use in a SetPermissions transaction. 
Only an QA Chip programmed with correct value of Kn can respond correctly to the SignP request. 
The output bytestream from the SignP command can be fed as the input bytestream to the 
SetPermissions command on a different QA Chip. 

20 

The input bytestream consists of the SMP opcode followed by 1 byte containing the key number to 
use for generating the signature, 20 bytes of Re (representing the number obtained from ChipU's 
RND command, and finally the desired P to write to ChipU. 

25 Since the SignP function generates signatures, the function must wait for the MinTicksRemaining 
register to reach 0 before processing takes place. 

Once all the inputs have been verified, the Paired is signed with an updated Rl (and the passed in 
Re), and both values are output (the random number Rl and the signature). The time taken to 
30 generate this signature must be the same regardless of the inputs. 

Typically, the SignP command will be acting as a form of consumable command, so that a given 
ChipS can only generate a given number of signatures. The actual number can conveniently be 
stored in Mo (eg word 0 of Mo) with Readonly permissions. Of course another chip could perform an 
35 Authorised write to update the number (using another ChipS) should it be desired. 

The SignM command is implemented with the following steps: 
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Wait for MinTicksRemaining to become 0 

Loop through all of Flash, reading each word (will trigger checks) 

Accept n 
5 Restrict n to N 

Accept R E 

Accept P d esired 

If (M L [0] = 0) # fail if allowed sigs = 0 

Output appropriate number of 0 # report failure 

1 0 Done 
Endlf 

Update R L 
Output R L 

15 Sig <- SktJReIRlI Pdesired I C 2 ] # calculation must take constant time 

MinTicksRemaining <- MinTicks 

Decrement M L [0] # reduce the number of allowable signatures by 

1 

Output Sig 

20 

15.1.13 Test 

Input: n, Re, Me, SIGe = [1 byte, 20 bytes, 64 bytes, 20 bytes] 

Output: Boolean (0x76=failure, 0x89 = success) 
Changes: Rl 

25 

The Test command is used to authenticate a read of an M from a non-trusted QA Chip. 

The Test command consists of the TST command opcode followed by input parameters: n, Re, Me, 
and SIGe. The byte order is least significant byte to most significant byte for each command 
30 component. All but the first input parameter bytes are obtained as the output bytes from a Read 
command to a non-trusted QA Chip. The entire data does not have to be stored by the client. 
Instead, the bytes can be passed directly to the trusted QA Chip's Test command, and only M 
should be kept from the Read. 

35 Calls to Test must wait for the MinTicksRemaining register to reach 0. 

Skji[Rl|Re|Ci|Me] is then calculated, and compared against the input signature SIGe. If they are 
different, Rl is not changed, and 0x76 is returned to indicate failure. If they are the same, then Rl is 
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updated to be the next random number in the sequence and 0x89 is returned to indicate success. 
Updating Ri only after success forces the caller to use a new random number (via the Random 
command) each time a successful authentication is performed. 

5 The calculation of SKn[Ri_|RE|Ci|ME] and the comparison against SIGe must take identical time so that 
the time to evaluate the comparison in the TST function is always the same. Thus no attacker can 
compare execution times or number of bits processed before an output is given. 

The Test command is implemented with the following steps: 
10 Wait for MinTicksRemaining to become 0 

Loop through all of Flash, reading each word (will trigger checks) 

Accept n 
Restrict n to N 
15 Accept R E 

Accept M E 

SIG L <- Skh [R L | R E | Cx | M E ] # calculation must take constant time 
Accept SIG E 
If (SIG E = SXG h ) 
20 Update R L 

Output 0x8 9 # success 
Else 

Output 0x76 # report failure 

Endlf 

25 MinTicksRemaining <- MinTicks 

15.1.14 Write 

Input: t, Mnew, SIGe = [1 byte, 64 bytes, 20 bytes] 

Output: Boolean (0x76=failure, 0x89 = success) 
Changes: Mt 

30 The Write command is used to update Mt according to the permissions in Pt. The WR command by 
itself is not secure, since a clone QA Chip may simply return success every time. Therefore a Write 
command should be followed by an authenticated read of Mt (e.g. via a Read command) to ensure 
that the change was actually made. 

The Write command is called by passing the WR command opcode followed by which M to be 
35 updated, the new data to be written to M, and a digital signature of M. The data is sent least 
significant byte to most significant byte. 
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The ability to write to a specific 32-bit word within Mt is governed by the corresponding Permissions 
bits as stored in Pt. Pt can be set using the SetPermissions command. 

The fact that Mt is Flash memory must be taken into account when writing the new value to M. It is 
possible for an attacker to remove power at any time. In addition, only the changes to M should be 
5 stored for maximum utilization. In addition, the longevity of M will need to be taken into account. 
This may result in the location of M being updated. 

The signature is not keyed, since it must be generated by the consumable user. 
The Write command is implemented with the following steps: 

Loop through all of Flash, reading each word (will trigger checks) 
1 0 Accept t 

Restrict t to T 

Accept M E # new M 

Accept SIG E 

15 SIG L = Generate SHA1 [M E ] 

If (SIG L = SIGb) 

output 0x76 # failure due to invalid signature 
exit 
Endlf 

20 DecEncountered <— 0 

EqEncountered <— 0 

For i <— msw to lsw # (word 15 to 0) 
P <r- P t [i] 

LT <r- (M E [i] < M t [i]) # comparison is unsigned 
25 EQ <r- (Me [i] = M t [i] ) 

WE <— (P = RW) V ( (P = MSR) A LT) V ( (P = NMSR) A 
(DecEncountered v LT) ) 

DecEncountered <— ( (P = MSR) a LT) 

v ( (p = NMSR) a DecEncountered) 
30 v ( (P = NMSR) a EqEncountered a LT) 

EqEncountered <- ( (P = MSR) a EQ) v ( (P = NMSR) a EqEncountered 
a EQ) 

If (-.WE) a (M E [i] * M t [i] ) 
35 output 0x76 # failure due to wanting a change but not allowed 

it 
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Endlf 
EndFor 



# At this point, M E (desired) is correct to be written to the 
5 flash 

Mt <- M E # update flash 

output 0x89 # success 

15.1.15 WriteAuth 

Input: n, Re, Me, SIGe = [1 byte, 20 bytes, 64 bytes, 20 bytes] 

1 0 Output: Boolean (0x76=failure, 0x8 9 = success) 

Changes: Mo, Rl 

The WriteAuth command is used to securely replace the entire contents of Mo (containing QA Chip 
application specific data) according to the Pt-*,. The WriteAuth command only attempts to replace Mo 
if the new value is signed combined with our local R. 
15 It is only possible to sign messages by knowing Kn. This can be achieved by a call to the SignM 
command (because only a ChipS can know Kn). It means that without a chip that can be used to 
produce the required signature, a write of any value to Mo is not possible. 

The process is very similar to Write, except that if the validation succeeds, the Me input parameter is 
processed against Mo using permissions Pt*o. 
20 The WriteAuth command is implemented with the following steps: 
Wait for MinTicksRemaining to become 0 

Loop through all of Flash, reading each word (will trigger checks) 

Accept n 
25 Restrict n to N 

Accept R E 
Accept M E 

SIG L <- Skh[Rl|Re|Ci|m e ] # calculation must take constant time 
Accept SIG E 
30 If (SIGe = SIGJ 

Update R L 

DecEncountered <— 0 
EqEncountered «— 0 

For i <— msw to lsw # (word 15 to 0) 
35 P <- P T+n [i] 

LT <- ( M E [ i ] < M 0 [i]) # comparison is unsigned 
EQ <- (M s Ci] = Mo[i] ) 
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WE <— (P = RW) V ( (P = MSR) A LT) V ( (P = NMSR) A 
(DecEncountered v LT) ) 

DecEncountered ( (P = MSR) a LT) 

v ( (P = NMSR) a DecEncountered) 
5 v ( (P = NMSR) a EqEncountered a LT) 

EqEncountered <- ( (P = MSR) a EQ) v ( (P = NMSR) a 
EqEncountered a EQ) 

If ((-.WE) a (Me [i] *M 0 [i])) 

output 0x76 # failure due to wanting a change but not 
10 allowed it 

Endlf 
EndFor 

# At this point, M E (desired) is correct to be written to the 
flash 

15 M 0 <- M E # update flash 

output 0x8 9 # success 

Endlf 

MinTicksRemaining <— MinTicks 
16 Manufacture 

20 This chapter makes some general comments about the manufacture and implementation of 
authentication chips. While the comments presented here are general, see [84] for a detailed 
description of an implementation of an authentication chip. 

The authentication chip algorithms do not constitute a strong encryption device. The net effect is 
that they can be safely manufactured in any country (including the USA) and exported to anywhere 
25 in the world. 

The circuitry of the authentication chip must be resistant to physical attack. A summary of 
manufacturing implementation guidelines is presented, followed by specification of the chip's 
physical defenses (ordered by attack). 

Note that manufacturing comments are in addition to any legal protection undertaken, such as 
30 patents, copyright, and license agreements (for example, penalties if caught reverse engineering 
the authentication chip). 
16.1 Guidelines for Manufacturing 

The following are general guidelines for implementation of an authentication chip in terms of 
manufacture (see [84] for a detailed description of an authentication chip). No special security is 
35 required during the manufacturing process. 
© Standard process 
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o Minimum size (if possible) 

o Clock Filter 

o Noise Generator 

o Tamper Prevention and Detection circuitry 
5 o Protected memory with tamper detection 
o Boot circuitry for loading program code 
o Special implementation of FETs for key data paths 
o Data connections in polysilicon layers where possible 
o OverUnderPower Detection Unit 
10 © No test circuitry 

o Transparent epoxy packaging 

Finally, as a general note to manufacturers of Systems, the data line to the System authentication 
chip and the data line to the Consumable authentication chip must not be the same line. See 
Section 16.2.3 on page 736. 
15 16.1.1 Standard Process 

The authentication chip should be implemented with a standard manufacturing process (such as 
Flash). This is necessary to: 

o allow a great range of manufacturing location options 
o take advantage of well-defined and well-behaved technology 
20 o reduce cost 

Note that the standard process still allows physical protection mechanisms. 

16.1.2 Minimum size 

The authentication chip must have a low manufacturing cost in order to be included as the 
authentication mechanism for low cost consumables. It is therefore desirable to keep the chip size 

25 as low as reasonably possible. 

Each authentication chip requires 962 bits of non-volatile memory. In addition, the storage required 
for optimized HMAC-SHA1 is 1024 bits. The remainder of the chip (state machine, processor, CPU 
or whatever is chosen to implement Protocol C1) must be kept to a minimum in order that the 
number of transistors is minimized and thus the cost per chip is minimized. The circuit areas that 

30 process the secret key information or could reveal information about the key should also be 
minimized (see Section 16.1 .8 on page 734 for special data paths). 

16.1.3 Clock Filter 

The authentication chip circuitry is designed to operate within a specific clock speed range. Since 
the user directly supplies the clock signal, it is possible for an attacker to attempt to introduce race- 
35 conditions in the circuitry at specific times during processing. An example of this is where a high 
clock speed (higher than the circuitry is designed for) may prevent an XOR from working properly, 
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and of the two inputs, the first may always be returned. These styles of transient fault attacks can 
be very efficient at recovering secret key information, and have been documented in [5] and [1], 
The lesson to be learned from this is that the input clock signal cannot be trusted. 
Since the input clock signal cannot be trusted, it must be limited to operate up to a maximum 
5 frequency. This can be achieved a number of ways. 

One way to filter the clock signal is to use an edge detect unit passing the edge on to a delay, 
which in turn enables the input clock signal to pass through. 
Figure 348 shows clock signal flow within the Clock Filter. 

The delay should be set so that the maximum clock speed is a particular frequency (e.g. about 4 
1 0 MHz). Note that this delay is not programmable - it is fixed. 

The filtered clock signal would be further divided internally as required. 

1 6.1 .4 Noise Generator 

Each authentication chip should contain a noise generator that generates continuous circuit noise. 
The noise will interfere with other electromagnetic emissions from the chip's regular activities and 
1 5 add noise to the l dd signal. Placement of the noise generator is not an issue on an authentication 
chip due to the length of the emission wavelengths. 

The noise generator is used to generate electronic noise, multiple state changes each clock cycle, 
and as a source of pseudo-random bits for the Tamper Prevention and Detection circuitry (see 
Section 16.1.5 on page 731). 
20 A simple implementation of a noise generator is a 64-bit maximal period LFSR seeded with a non- 
zero number. The clock used for the noise generator should be running at the maximum clock rate 
for the chip in order to generate as much noise as possible. 

16.1 .5 Tamper Prevention and Detection circuitry 

A set of circuits is required to test for and prevent physical attacks on the authentication chip. 
25 However what is actually detected as an attack may not be an intentional physical attack. It is 
therefore important to distinguish between these two types of attacks in an authentication chip: 
o where you can be certain that a physical attack has occurred, 
o where you cannot be certain that a physical attack has occurred. 

The two types of detection differ in what is performed as a result of the detection. In the first case, 
30 where the circuitry can be certain that a true physical attack has occurred, erasure of Flash memory 
key information is a sensible action. In the second case, where the circuitry cannot be sure if an 
attack has occurred, there is still certainly something wrong. Action must be taken, but the action 
should not be the erasure of secret key information. A suitable action to take in the second case is 
a chip RESET. If what was detected was an attack that has permanently damaged the chip, the 
35 same conditions will occur next time and the chip will RESET again. If, on the other hand, what was 
detected was part of the normal operating environment of the chip, a RESET will not harm the key. 
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A good example of an event that circuitry cannot have knowledge about, is a power glitch. The 
glitch may be an intentional attack, attempting to reveal information about the key. It may, however, 
be the result of a faulty connection, or simply the start of a power-down sequence. It is therefore 
best to only RESET the chip, and not erase the key. If the chip was powering down, nothing is lost. 
5 If the System is faulty, repeated RESETS will cause the consumer to get the System repaired. In 
both cases the consumable is still intact. 

A good example of an event that circuitry can have knowledge about, is the cutting of a data line 
within the chip. If this attack is somehow detected, it could only be a result of a faulty chip 
(manufacturing defect) or an attack. In either case, the erasure of the secret information is a 

1 0 sensible step to take. 

Consequently each authentication chip should have 2 Tamper Detection Lines - one for definite 
attacks, and one for possible attacks. Connected to these Tamper Detection Lines would be a 
number of Tamper Detection test units, each testing for different forms of tampering. In addition, we 
want to ensure that the Tamper Detection Lines and Circuits themselves cannot a/so be tampered 

15 with. 

At one end of the Tamper Detection Line is a source of pseudo-random bits (clocking at high speed 
compared to the general operating circuitry). The Noise Generator circuit described above is an 
adequate source. The generated bits pass through two different paths - one carries the original 
data, and the other carries the inverse of the data. The wires carrying these bits are in the layer 

20 above the general chip circuitry (for example, the memory, the key manipulation circuitry etc.). The 
wires must also cover the random bit generator. The bits are recombined at a number of places via 
an XOR gate. If the bits are different (they should be), a 1 is output, and used by the particular unit 
(for example, each output bit from a memory read should be ANDed with this bit value). The lines 
finally come together at the Flash memory Erase circuit, where a complete erasure is triggered by a 

25 0 from the XOR. Attached to the line is a number of triggers, each detecting a physical attack on the 
chip. Each trigger has an oversize nMOS transistor attached to GND. The Tamper Detection Line 
physically goes through this nMOS transistor. If the test fails, the trigger causes the Tamper Detect 
Line to become 0. The XOR test will therefore fail on either this clock cycle or the next one (on 
average), thus RESETing or erasing the chip. 

30 Figure 349 illustrates the basic principle of a Tamper Detection Line in terms of tests and the XOR 
connected to either the Erase or RESET circuitry. 

The Tamper Detection Line must go through the drain of an output transistor for each test, as 
illustrated by Figure 350: 

It is not possible to break the Tamper Detect Line since this would stop the flow of 1s and 0s from 
35 the random source. The XOR tests would therefore fail. As the Tamper Detect Line physically 
passes through each test, it is not possible to eliminate any particular test without breaking the 
Tamper Detect Line. 
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It is important that the XORs take values from a variety of places along the Tamper Detect Lines in 
order to reduce the chances of an attack. Figure 351 illustrates the taking of multiple XORs from the 
Tamper Detect Line to be used in the different parts of the chip. Each of these XORs can be 
considered to be generating a ChipOK bit that can be used within each unit or sub-unit. 
5 A sample usage would be to have an OK bit in each unit that is ANDed with a given ChipOK bit 
each cycle. The OK bit is loaded with 1 on a RESET. If OK is 0, that unit will fail until the next 
RESET. If the Tamper Detect Line is functioning correctly, the chip will either RESET or erase all 
key information. If the RESET or erase circuitry has been destroyed, then this unit will not function, 
thus thwarting an attacker. 
1 0 The destination of the RESET and Erase line and associated circuitry is very context sensitive. It 
needs to be protected in much the same way as the individual tamper tests. There is no point 
generating a RESET pulse if the attacker can simply cut the wire leading to the RESET circuitry. 
The actual implementation will depend very much on what is to be cleared at RESET, and how 
those items are cleared. 

1 5 Finally, Figure 352 shows how the Tamper Lines cover the noise generator circuitry of the chip. The 
generator and NOT gate are on one level, while the Tamper Detect Lines run on a level above the 
generator. 

1 6.1 .6 Protected memory with tamper detection 

It is not enough to simply store secret information or program code in Flash memory. The Flash 
20 memory and RAM must be protected from an attacker who would attempt to modify (or set) a 

particular bit of program code or key information. The mechanism used must conform to being used 
in the Tamper Detection Circuitry (described above). 

The first part of the solution is to ensure that the Tamper Detection Line passes directly above each 
Flash or RAM bit. This ensures that an attacker cannot probe the contents of Flash or RAM. A 
25 breach of the covering wire is a break in the Tamper Detection Line. The breach causes the Erase 
signal to be set, thus deleting any contents of the memory. The high frequency noise on the 
Tamper Detection Line also obscures passive observation. 

The second part of the solution for Flash is to use multi-level data storage, but only to use a subset 
of those multiple levels for valid bit representations. Normally, when multi-level Flash storage is 

30 used, a single floating gate holds more than one bit. For example, a 4-voltage-state transistor can 
represent two bits. Assuming a minimum and maximum voltage representing 00 and 1 1 
respectively, the two middle voltages represent 01 and 10. In the authentication chip, we can use 
the two middle voltages to represent a single bit, and consider the two extremes to be invalid 
states. If an attacker attempts to force the state of a bit one way or the other by closing or cutting 

35 the gate's circuit, an invalid voltage (and hence invalid state) results. 

The second part of the solution for RAM is to use a parity bit. The data part of the register can be 
checked against the parity bit (which will not match after an attack). 
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The bits coming from Flash and RAM can therefore be validated by a number of test units (one per 
bit) connected to the common Tamper Detection Line. The Tamper Detection circuitry would be the 
first circuitry the data passes through (thus stopping an attacker from cutting the data lines). 
While the multi-level Flash protection is enough for non-secret information, such as program code, 
5 R, and MinTicks, it is not sufficient for protecting and K 2 . If an attacker adds electrons to a gate 
(see Section 5.7.2.15 on page 656) representing a single bit of K-,, and the chip boots up yet 
doesn't activate the Tamper Detection Line, the key bit must have been a 0. If it does activate the 
Tamper Detection Line, it must have been a 1 . For this reason, all other non-volatile memory can 
activate the Tamper Detection Line, but and K 2 must not. Consequently Checksum is used to 
1 0 check for tampering of K-i and K 2 . A signature of the expanded form of and K 2 (i.e. 320 bits 
instead of 160 bits for each of IC, and K 2 ) is produced, and the result compared against the 
Checksum. Any non-match causes a clear of all key information. 

16.1.7 Boot circuitry for loading program code 

Program code should be kept in multi-level Flash instead of ROM, since ROM is subject to being 
1 5 altered in a non-testable way. A boot mechanism is therefore required to load the program code 
into Flash memory (Flash memory is in an indeterminate state after manufacture). 
The boot circuitry must not be in ROM - a small state-machine would suffice. Otherwise the boot 
code could be modified in an undetectable way. 

The boot circuitry must erase all Flash memory, check to ensure the erasure worked, and then load 
20 the program code. Flash memory must be erased before loading the program code. Otherwise an 
attacker could put the chip into the boot state, and then load program code that simply extracted the 
existing keys. The state machine must also check to ensure that all Flash memory has been 
cleared (to ensure that an attacker has not cut the Erase line) before loading the new program 
code. 

25 The loading of program code must be undertaken by the secure Programming Station before secret 
information (such as keys) can be loaded. This step must be undertaken as the first part of the 
programming process. 

16.1 .8 Special implementation of FETs for key data paths 

The normal situation for FET implementation for the case of a CMOS Inverter (which involves a 
30 pMOS transistor combined with an nMOS transistor) as shown in Figure 353: 

During the transition, there is a small period of time where both the nMOS transistor and the pMOS 
transistor have an intermediate resistance. The resultant power-ground short circuit causes a 
temporary increase in the current, and in fact accounts for the majority of current consumed by a 
CMOS device. A small amount of infrared light is emitted during the short circuit, and can be viewed 
35 through the silicon substrate (silicon is transparent to infrared light). A small amount of light is also 
emitted during the charging and discharging of the transistor gate capacitance and transmission 
line capacitance. 
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For circuitry that manipulates secret key information, such information must be kept hidden. An 
alternative non-flashing CMOS implementation should therefore be used for all data paths that 
manipulate the key or a partially calculated value that is based on the key. 
The use of two non-overlapping clocks <J>1 and §2 can provide a non-flashing mechanism. <j>1 is 
5 connected to a second gate of all nMOS transistors, and <J>2 is connected to a second gate of all 

pMOS transistors. The transition can only take place in combination with the clock. Since <|>1 and 4>2 
are non-overlapping, the pMOS and nMOS transistors will not have a simultaneous intermediate 
resistance. The setup is shown in Figure 354: 

Finally, regular CMOS inverters can be positioned near critical non-Flashing CMOS components. 

1 0 These inverters should take their input signal from the Tamper Detection Line above. Since the 
Tamper Detection Line operates multiple times faster than the regular operating circuitry, the net 
effect will be a high rate of light-bursts next to each non-Flashing CMOS component. Since a bright 
light overwhelms observation of a nearby faint light, an observer will not be able to detect what 
switching operations are occurring in the chip proper. These regular CMOS inverters will also 

1 5 effectively increase the amount of circuit noise, reducing the SNR and obscuring useful EMI. 
There are a number of side effects due to the use of non-Flashing CMOS: 

o The effective speed of the chip is reduced by twice the rise time of the clock per clock cycle. 

This is not a problem for an authentication chip. 
o The amount of current drawn by the non-Flashing CMOS is reduced (since the short circuits 
20 do not occur). However, this is offset by the use of regular CMOS inverters. 

© Routing of the clocks increases chip area, especially since multiple versions of 4>1 and <|>2 are 

required to cater for different levels of propagation. The estimation of chip area is double that 

of a regular implementation, 
o Design of the non-Flashing areas of the authentication chip are slightly more complex than to 
25 do the same with a with a regular CMOS design. In particular, standard cell components 

cannot be used, making these areas full custom. This is not a problem for something as 

small as an authentication chip, particularly when the entire chip does not have to be 

protected in this manner. 

16.1 .9 Connections in polysilicon layers where possible 

30 Wherever possible, the connections along which the key or secret data flows, should be made in 
the polysilicon layers. Where necessary, they can be in metal 1, but must never be in the top metal 
layer (containing the Tamper Detection Lines). 

16.1 .10 OverUnderPower Detection Unit 

Each authentication chip requires an OverUnderPower Detection Unit to prevent Power Supply 
35 Attacks. An OverUnderPower Detection Unit detects power glitches and tests the power level 

against a Voltage Reference to ensure it is within a certain tolerance. The Unit contains a single 
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Voltage Reference and two comparators. The OverUnderPower Detection Unit would be connected 
into the RESET Tamper Detection Line, thus causing a RESET when triggered. 
A side effect of the OverUnderPower Detection Unit is that as the voltage drops during a power- 
down, a RESET is triggered, thus erasing any work registers. 
5 16.1.11 No test circuitry 

Test hardware on an authentication chip could very easily introduce vulnerabilities. As a result, the 
authentication chip should not contain any BIST or scan paths. 

The authentication chip must therefore be testable with external test vectors. This should be 
possible since the authentication chip is not complex. 

10 1 6.1 .1 2 Transparent epoxy packaging 

The authentication chip needs to be packaged in transparent epoxy so it can be photo-imaged by 
the programming station to prevent Trojan horse attacks. The transparent packaging does not 
compromise the security of the authentication chip since an attacker can fairly easily remove a chip 
from its packaging. For more information see Section 16.2.20 on page 743 and [86]. 

15 16.2 Resistance To Physical Attacks 

While this chapter only describes manufacture in general terms (since this document does not 
cover a specific implementation of a Protocol C1 authentication chip), we can still make some 
observations about such a chip's resistance to physical attack. A description of the general form of 
each physical attack can be found in Section 5.7.2 on page 652. 

20 16.2.1 Reading ROM 

This attack depends on the key being stored in an addressable ROM. Since each authentication 
chip stores its authentication keys in internal Flash memory and not in an addressable ROM, this 
attack is irrelevant. 

1 6.2.2 Reverse engineering the chip 

25 Reverse engineering a chip is only useful when the security of authentication lies in the algorithm 
alone. However our authentication chips rely on a secret key, and not in the secrecy of the 
algorithm. Our authentication algorithm is, by contrast, public, and in any case, an attacker of a high 
volume consumable is assumed to have been able to obtain detailed plans of the internals of the 
chip. 

30 In light of these factors, reverse engineering the chip itself, as opposed to the stored data, poses no 
threat. 

16.2.3 Usurping the authentication process 

There are several forms this attack can take, each with varying degrees of success. In all cases, it 
is assumed that a clone manufacturer will have access to both the System and the consumable 
35 designs. 

An attacker may attempt to build a chip that tricks the System into returning a valid code instead of 
generating an authentication code. This attack is not possible for two reasons. The first reason is 
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that System authentication chips and Consumable authentication chips, although physically 
identical, are programmed differently. In particular, the RD opcode and the RND opcode are the 
same, as are the WR and TST opcodes. A System authentication Chip cannot perform a RD 
command since every call is interpreted as a call to RND instead. The second reason this attack 
5 would fail is that separate serial data lines are provided from the System to the System and 

Consumable authentication chips. Consequently neither chip can see what is being transmitted to 
or received from the other. 

If the attacker builds a clone chip that ignores WR commands (which decrement the consumable 
remaining), Protocol C1 ensures that the subsequent RD will detect that the WR did not occur. The 
1 0 System will therefore not go ahead with the use of the consumable, thus thwarting the attacker. The 
same is true if an attacker simulates loss of contact before authentication - since the authentication 
does not take place, the use of the consumable doesn't occur. 

An attacker is therefore limited to modifying each System in order for clone consumables to be 
accepted (see Section 16.2.4 on page 737 for details of resistance this attack). 

1 5 1 6.2.4 Modification of system 

The simplest method of modification is to replace the System's authentication chip with one that 
simply reports success for each call to TST. This can be thwarted by System calling TST several 
times for each authentication, with the first few times providing false values, and expecting a fail 
from TST. The final call to TST would be expected to succeed. The number of false calls to TST 

20 could be determined by some part of the returned result from RD or from the system clock. 

Unfortunately an attacker could simply rewire System so that the new System clone authentication 
chip can monitor the returned result from the consumable chip or clock. The clone System 
authentication chip would only return success when that monitored value is presented to its TST 
function. Clone consumables could then return any value as the hash result for RD, as the clone 

25 System chip would declare that value valid. There is therefore no point for the System to call the 

System authentication chip multiple times, since a rewiring attack will only work for the System that 
has been rewired, and not for all Systems. 

A similar form of attack on a System is a replacement of the System ROM. The ROM program code 
can be altered so that the Authentication never occurs. There is nothing that can be done about 
30 this, since the System remains in the hands of a consumer. Of course this would void any warranty, 
but the consumer may consider the alteration worthwhile if the clone consumable were extremely 
cheap and more readily available than the original item. 

The System/consumable manufacturer must therefore determine how likely an attack of this nature 
is. Such a study must include given the pricing structure of Systems and Consumables, frequency 
35 of System service, advantage to the consumer of having a physical modification performed, and 
where consumers would go to get the modification performed. 
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The likelihood of physical alteration increases with the perceived artificiality of the consumable 
marketing scheme. It is one thing for a consumable to be protected against clone manufacturers. It 
is quite another for a consumable's market to be protected by a form of exclusive licensing 
arrangement that creates what is viewed by consumers as artificial markets. In the former case, 
5 owners are not so likely to go to the trouble of modifying their system to allow a clone 

manufacturer's goods. In the latter case, consumers are far more likely to modify their System. A 
case in point is DVD. Each DVD is marked with a region code, and will only play in a DVD player 
from that region. Thus a DVD from the USA will not play in an Australian player, and a DVD from 
Japan, Europe or Australia will not play in a USA DVD player. Given that certain DVD titles are not 

1 0 available in all regions, or because of quality differences, pricing differences or timing of releases, 
many consumers have had their DVD players modified to accept DVDs from any region. The 
modification is usually simple (it often involves soldering a single wire), voids the owner's warranty, 
and often costs the owner some money. But the interesting thing to note is that the change is not 
made so the consumer can use clone consumables - the consumer will still only buy real 

1 5 consumables, but from different regions. The modification is performed to remove what is viewed 
as an artificial barrier, placed on the consumer by the movie companies. In the same way, a 
System/Consumable scheme that is viewed as unfair will result in people making modifications to 
their Systems. 

The limit case of modifying a system is for a clone manufacturer to provide a completely clone 
20 System which takes clone consumables. This may be simple competition or violation of patents. 
Either way, it is beyond the scope of the authentication chip and depends on the technology or 
service being cloned. 

1 6.2.5 Direct viewing of chip operation by conventional probing 

In order to view the chip operation, the chip must be operating. However, the Tamper Prevention 
25 and Detection circuitry covers those sections of the chip that process or hold the key. It is not 
possible to view those sections through the Tamper Prevention lines. 

An attacker cannot simply slice the chip past the Tamper Prevention layer, for this will break the 
Tamper Detection Lines and cause an erasure of all keys at power-up. Simply destroying the 
erasure circuitry is not sufficient, since the multiple ChipOK bits (now all 0) feeding into multiple 
30 units within the authentication chip will cause the chip's regular operating circuitry to stop 
functioning. 

To set up the chip for an attack, then, requires the attacker to delete the Tamper Detection lines, 
stop the Erasure of Flash memory, and somehow rewire the components that relied on the ChipOK 
lines. Even if all this could be done, the act of slicing the chip to this level will most likely destroy the 
35 charge patterns in the non-volatile memory that holds the keys, making the process fruitless. 

1 6.2.6 Direct viewing of the non-volatile memory 
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If the authentication chip were sliced so that the floating gates of the Flash memory were exposed, 
without discharging them, then the keys could probably be viewed directly using an STM or SKM. 
However, slicing the chip to this level without discharging the gates is probably impossible. Using 
wet etching, plasma etching, ion milling, or chemical mechanical polishing will almost certainly 
5 discharge the small charges present on the floating gates. This is true of regular Flash memory, but 
even more so of multi-level Flash memory. 

16.2.7 Viewing the light bursts caused by state changes 

All sections of circuitry that manipulate secret key information are implemented in the non-Flashing 
CMOS described above. This prevents the emission of the majority of light bursts. Regular CMOS 
1 0 inverters placed in close proximity to the non-Flashing CMOS will hide any faint emissions caused 
by capacitor charge and discharge. The inverters are connected to the Tamper Detection circuitry, 
so they change state many times (at the high clock rate) for each non-Flashing CMOS state 
change. 

1 6.2.8 Viewing the keys using an SEPM 

15 An SEPM attack can be simply thwarted by adding a metal layer to cover the circuitry. However an 
attacker could etch a hole in the layer, so this is not an appropriate defense. 

The Tamper Detection circuitry described above will shield the signal as well as cause circuit noise. 
The noise will actually be a greater signal than the one that the attacker is looking for. If the attacker 
attempts to etch a hole in the noise circuitry covering the protected areas, the chip will not function, 
20 and the SEPM will not be able to read any data. 
An SEPM attack is therefore fruitless. 

16.2.9 Monitoring EMI 

The Noise Generator described above will cause circuit noise. The noise will interfere with other 
electromagnetic emissions from the chip's regular activities and thus obscure any meaningful 
25 reading of internal data transfers. 

16.2.10 Viewing l dd fluctuations 

The solution against this kind of attack is to decrease the SNR in the l dd signal. This is 
accomplished by increasing the amount of circuit noise and decreasing the amount of signal. 
The Noise Generator circuit (which also acts as a defense against EMI attacks) will also cause 
30 enough state changes each cycle to obscure any meaningful information in the l dd signal. 

In addition, the special Non-Flashing CMOS implementation of the key-carrying data paths of the 
chip prevents current from flowing when state changes occur. This has the benefit of reducing the 
amount of signal. 

1 6.2.1 1 Differential fault analysis 

35 Differential fault bit errors are introduced in a non-targeted fashion by ionization, microwave 

radiation, and environmental stress. The most likely effect of an attack of this nature is a change in 
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Flash memory (causing an invalid state) or RAM (bad parity). Invalid states and bad parity are 
detected by the Tamper Detection Circuitry, and cause an erasure of the key. 
Since the Tamper Detection Lines cover the key manipulation circuitry, any error introduced in the 
key manipulation circuitry will be mirrored by an error in a Tamper Detection Line. If the Tamper 
5 Detection Line is affected, the chip will either continually RESET or simply erase the key upon a 
power-up, rendering the attack fruitless. 

Rather than relying on a non-targeted attack and hoping that "just the right part of the chip is 
affected in just the right way", an attacker is better off trying to introduce a targeted fault (such as 
overwrite attacks, gate destruction etc.). For information on these targeted fault attacks, see the 
1 0 relevant sections below. 

16.2.12 Clock glitch attacks 

The Clock Filter (described above) eliminates the possibility of clock glitch attacks. 

1 6.2.1 3 Power supply attacks 

The OverUnderPower Detection Unit (described above) eliminates the possibility of power supply 
1 5 attacks. 

16.2.14 Overwriting ROM 

Authentication chips store program code, keys and secret information in Flash memory, and not in 
ROM. This attack is therefore not possible. 

16.2.15 Modifying EEPROM/Flash 

20 Authentication chips store program code, keys and secret information in multi-level Flash memory. 
However the Flash memory is covered by two Tamper Prevention and Detection Lines. If either of 
these lines is broken (in the process of destroying a gate via a laser-cutter) the attack will be 
detected on power-up, and the chip will either RESET (continually) or erase the keys from Flash 
memory. This process is described in Section 16.1.6 on page 733. 

25 Even if an attacker is able to somehow access the bits of Flash and destroy or short out the gate 
holding a particular bit, this will force the bit to have no charge or a full charge. These are both 
invalid states for the authentication chip's usage of the multi-level Flash memory (only the two 
middle states are valid). When that data value is transferred from Flash, detection circuitry will 
cause the Erasure Tamper Detection Line to be triggered - thereby erasing the remainder of Flash 

30 memory and RESETing the chip. This is true for program code, and non-secret information. As key 
data is read from multi-level flash memory, it is not imediately checked for validity (otherwise 
information about the key is given away). Instead, a specific key validation mechanism is used to 
protect the secret key information. 

An attacker could theoretically etch off the upper levels of the chip, and deposit enough electrons to 
35 change the state of the multi-level Flash memory by 1/3. If the beam is high enough energy it might 
be possible to focus the electron beam through the Tamper Prevention and Detection Lines. As a 
result, the authentication chip must perform a validation of the keys before replying to the Random, 
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Test or Random commands. The SHA-1 algorithm must be run on the keys, and the results 
compared against an internal checksum value. This gives an attacker a 1 in 2 160 chance of tricking 
the chip, which is the same chance as guessing either of the keys. 
A Modify EEPROM/Flash attack is therefore fruitless. 
5 1 6.2.1 6 Gate destruction attacks 

Gate Destruction Attacks rely on the ability of an attacker to modify a single gate to cause the chip 
to reveal information during operation. However any circuitry that manipulates secret information is 
covered by one of the two Tamper Prevention and Detection lines. If either of these lines is broken 
(in the process of destroying a gate) the attack will be detected on power-up, and the chip will either 

1 0 RESET (continually) or erase the keys from Flash memory. 

To launch this kind of attack, an attacker must first reverse-engineer the chip to determine which 
gate(s) should be targeted. Once the location of the target gates has been determined, the attacker 
must break the covering Tamper Detection line, stop the Erasure of Flash memory, and somehow 
rewire the components that rely on the ChipOK lines. Rewiring the circuitry cannot be done without 

1 5 slicing the chip, and even if it could be done, the act of slicing the chip to this level will most likely 
destroy the charge patterns in the non-volatile memory that holds the keys, making the process 
fruitless. 

16.2.17 Overwrite attack 

An overwrite attack relies on being able to set individual bits of the key without knowing the 
20 previous value. It relies on probing the chip, as in the conventional probing attack and destroying 
gates as in the gate destruction attack. Both of these attacks (as explained in their respective 
sections), will not succeed due to the use of the Tamper Prevention and Detection Circuitry and 
ChipOK lines. 

However, even if the attacker is able to somehow access the bits of Flash and destroy or short out 
25 the gate holding a particular bit, this will force the bit to have no charge or a full charge. These are 
both invalid states for the authentication chip's usage of the multi-level Flash memory (only the two 
middle states are valid). When that data value is transferred from Flash detection circuitry will cause 
the Erasure Tamper Detection Line to be triggered - thereby erasing the remainder of Flash 
memory and RESETing the chip. In the same way, a parity check on tampered values read from 
30 RAM will cause the Erasure Tamper Detection Line to be triggered. 
An overwrite attack is therefore fruitless. 

1 6.2. 1 8 Memory remanence attack 

Any working registers or RAM within the authentication chip may be holding part of the 
35 authentication keys when power is removed. The working registers and RAM would continue to 
hold the information for some time after the removal of power. If the chip were sliced so that the 
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gates of the registers/RAM were exposed, without discharging them, then the data could probably 
be viewed directly using an STM. 

The first defense can be found above, in the description of defense against power glitch attacks. 
When power is removed, all registers and RAM are cleared, just as the RESET condition causes a 
clearing of memory. 

The chances then, are less for this attack to succeed than for a reading of the Flash memory. RAM 
charges (by nature) are more easily lost than Flash memory. The slicing of the chip to reveal the 
RAM will certainly cause the charges to be lost (if they haven't been lost simply due to the memory 
not being refreshed and the time taken to perform the slicing). 

This attack is therefore fruitless. 
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16.2.19 Chip theft attack 

There are distinct phases in the lifetime of an authentication chip. Chips can be stolen when at any 
of these stages: 

© After manufacture, but before programming of key 
5 o After programming of key, but before programming of state data 

o After programming of state data, but before insertion into the consumable or system 

o After insertion into the system or consumable 
A theft in between the chip manufacturer and programming station would only provide the clone 
manufacturer with blank chips. This merely compromises the sale of authentication chips, not 
1 0 anything authenticated by the authentication chips. Since the programming station is the only 

mechanism with consumable and system product keys, a clone manufacturer would not be able to 
program the chips with the correct key. Clone manufacturers would be able to program the blank 
chips for their own Systems and Consumables, but it would be difficult to place these items on the 
market without detection. 

1 5 The second form of theft can only happen in a situation where an authentication chip passes 

through two or more distinct programming phases. This is possible, but unlikely. In any case, the 
worst situation is where no state data has been programmed, so all of M is read/write. If this were 
the case, an attacker could attempt to launch an adaptive chosen text attack on the chip. The 
HMAC-SHA1 algorithm is resistant to such attacks. For more information see Section 14.7 on 

20 page 699. 

The third form of theft would have to take place in between the programming station and the 
installation factory. The authentication chips would already be programmed for use in a particular 
system or for use in a particular consumable. The only use these chips have to a thief is to place 
them into a clone System or clone Consumable. Clone systems are irrelevant - a cloned System 

25 would not even require an authentication chip. For clone Consumables, such a theft would limit the 
number of cloned products to the number of chips stolen. A single theft should not create a supply 
constant enough to provide clone manufacturers with a cost-effective business. 
The final form of theft is where the System or Consumable itself is stolen. When the theft occurs at 
the manufacturer, physical security protocols must be enhanced. If the theft occurs anywhere else, 

30 it is a matter of concern only for the owner of the item and the police or insurance company. The 
security mechanisms that the authentication chip uses assume that the consumables and systems 
are in the hands of the public. Consequently, having them stolen makes no difference to the 
security of the keys. 

35 16.2.20 Trojan horse attack 

A Trojan horse attack involves an attacker inserting a fake authentication chip into the programming 
station and retrieving the same chip after it has been programmed with the secret key information. 
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The difficulty of these two tasks depends on both logical and physical security, but is an expensive 
attack - the attacker has to manufacture a false authentication chip, and it will only be useful where 
the effort is worth the gain. For example, obtaining the secret key for a specific car's authentication 
chip is most likely not worth an attacker's efforts, while the key for a printer's ink cartridge may be 
5 very valuable. 

The problem arises if the programming station is unable to tell a Trojan horse authentication chip 
from a real one - which is the problem of authenticating the authentication chip. 
One solution to the authentication problem is for the manufacturer to have a programming station 
attached to the end of the production line. Chips passing the manufacture OA tests are 

1 0 programmed with the manufacturer's secret key information. The chip can therefore be verified by 
the C1 authentication protocol, and give information such as the expected batch number, serial 
number etc. The information can be verified and recorded, and the valid chip can then be 
reprogrammed with the System or Consumable key and state data. An attacker would have to 
substitute an authentication chip with a Trojan horse programmed with the manufacturer's secret 

1 5 key information and copied batch number data from the removed authentication chip. This is only 
possible if the manufacturer's secret key is compromised (the key is changed regularly and not 
known by a human) or if the physical security at the manufacturing plant is compromised at the end 
of the manufacturing chain. 

Even if the solution described were to be undertaken, the possibility of a Trojan horse attack does 
20 not go away - it merely is removed to the manufacturer's physical location. A better solution 
requires no physical security at the manufacturing location. 

The preferred solution then, is to use transparent epoxy on the chip's packaging and to image the 
chip before programming it. Once the chip has been mounted for programming it is in a known fixed 
orientation. It can therefore be high resolution photo-imaged and X-rayed from multiple directions, 
25 and the images compared against "signature" images. Any chip not matching the image signature is 
treated as a Trojan horse and rejected. 
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1 REFILL OF INK IN PRINTERS - Printer based refill device 
1 . 1 Functional Purpose 

The functional purpose of the printer based refill device is as follows: 
o To refill ink into printers by physically connecting the refill device to the printer. 
5 o To ensure that the correct ink is used for the correct operation of the printer (i.e. will not damage the 
printhead). 

o To ensure accurate measure of ink is transferred from the refilling device to the printer during refills, 
o The refill device is controlled by the printer. Apart from the QA Chip 1 the refill device has no other 
processing power. 
10 1 .2 Basic Components of the refill device 

Figure 355 shows the components of the printer based refill device. 
The printer based refill device will consist of following components: 

o An ink reservoir - which stores the ink. Each refill device will allow ink reservoirs of various 

capacities. When the ink reservoir empties out, it is replaced by another reservoir containing more ink 
15 of the same type or different type or refilled (for example through a refill station as described in 

Section 2 and Section 3). 

o An ink output device- which dispenses ink to the printer being refilled when physically connected to 
the printer. 

o A QA Chip and associated circuitry - which stores the amount of ink in the reservoir along with the 
20 attributes of the ink in a digital format. 

o The electrical connections to the QA Chip. 

o NB - No additional microprocessors are required to be present in the refill device. Hence the refill 
device uses the processing power of the printer to oversee the refilling process. 

o An ink transfer mechanism (optional) which controls the flow ink from the refill device to the printer 
25 and is controlled by the printer. Therefore the control connections for the ink transfer mechanism will 

be connected to the printer. 

o Alternatively, the ink transfer mechanism could be in the printer. Refer to Section 1.3. 

1 .3 Printer description and functions 

Printers which will be refilled by these refilling devices must have the following components: 
30 o Microprocessor assembly which will control the refill procedure as described Section 1 A. The 

microprocessor assembly will access the QA Chip and ink transfer mechanism of the refill device. 
o A QA Chip storing the ink amount remaining in the printer. 



'Genera! Note: Througout this document, if secure refilling is required then a physical QA Chip or any other virtual 
device performing the QA Chip protocol can be used. Refer to [ 1 ]. 
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o An optional ink transfer mechanism to control the flow of ink from the refill device to the printer. This 
ink transfer mechanism must be present in the printer if the refill device doesn't have one of its own. 

1 .4 Operational procedure 

The operational procedure can be divided into two parts: 
o Refilling printers using the refill device. 

o Refilling of the ink reservoir in the refill device . See Section 2 and Section 3. 
1 .4.1 Refilling of printers 

Figure 356 shows a printer being refilled by a printer based refill device. The ink transfer mechanism is 
located in the printer in this case. The ink transfer mechanism could be also located in the refill device as 
described in Section 1.2. 

The following is a description for refilling of printers using the printer based refill device: 
o Ink output device from the refilling device is connected to the printer, 
o The QA Chip electrical connection is connected to the printer. 

o The refill option is selected on the user interface of the printer. The microprocessor assembly in the 
printer will then do the following: 

a. Read ink attributes (for example ink type, ink characteristics, ink colour, ink manufacturer etc) stored 
in the QA Chip of the ink reservoir unit. Refer to[l]. 

b. Compare the ink attributes as required by the printer for correct operation. This may require reading of 
data from the QA Chip in the printer. 

c. Only if Step b is successful, then do the following: 

i. Determine the amount of ink to be transferred by any or all of the following means, ensuring that the 
reservoir has enough ink for the transfer: 

o Fixed amount (e.g. based on a pre-programmed value or printer model), 

o User-selectable amount. 

ii. Decrement the amount of ink transferred from the QA Chip in the refill station and increment the QA 
Chip in the printer (which stores the amount of ink in the printer) with corresponding ink amount. 

iii. Command the ink transfer mechanism to release the ink to the printer through the output device. 
2 Home use refill station 

2.1 Functional Purpose 

The functional purpose of the commercial refill station is as follows: 
o To refill ink into ink cartridges at home or in a small office, 
o Single ink cartridge is filled at a time. 

o To ensure that the correct ink present in the refill station is transferred to the correct ink cartridge, 
o To ensure accurate measure of ink is transferred from the refilling station to the ink cartridge during 
refills. 

o The refilling station provides the processing power required to perform refills of ink cartridges. 

2.2 Basic Components 
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Figure 357 shows the components of a home refill station. 

A home refill station will consist of one of the following ink refill units: 

• A single reservoir ink refill unit suitable for black ink (or any other single colour). 

• A multi reservoir ink refill unit suitable for coloured ink for example CMY (Cyan, Magenta, Yellow). 
5 2.2.1 Ink reservoir unit 

Figure 358 shows the components of a three-ink reservoir unit. 
The ink reservoir unit will consist of the following: 

• Multiple ink reservoirs or a single ink reservoir which stores ink. Each refill station will allow ink 
reservoirs of various capacities. When the ink reservoir empties out, it is replaced by another reservoir 

1 0 containing more ink of the same or different type or refilled (for example through a refill station as 

described in Section 3). 

• A QA Chip and associated circuitry in each of the ink reservoirs - which stores the amount of ink in the 
reservoir along with the attributes of the ink. 

• The electrical connections to each of the QA Chips. 
15 2.2.2 Ink transfer unit 

The ink reservoir unit will consist of the following: 

• Ink output device from each ink reservoir. 

• The output ink transfer mechanism controls the flow ink from the ink refill unit to the ink cartridge and 
is controlled by the microprocessor assembly. 

20 • Final ink output devices to the cartridge interface assembly 

2.2.3 Cartridge interface unit 

This unit will provide the physical interface to the ink cartridges. Each ink cartridge interface unit will hold a 
single or multiple cartridges of particular physical dimension. 

The cartridge interface unit can removed from the ink refill unit and replaced with another interface unit to 
25 cater for other physically different cartridges. 

2.2.4 Microprocessor assembly 

The controls connections for the ink transfer mechanism and the electrical connections of the QA Chip are 
connected to the microprocessor assembly. The microprocessor assembly oversees and controls the refill 
process. 

30 The microprocessor assembly will communicate with a user interface to accept commands and provide 
responses for various refill operations. 

2.3 Ink cartridge description 

Ink cartridges which will be refilled in a home refill station must have a QA Chip storing the following 
components: 
35 • Ink amount remaining. 

• Ink attributes (for example - ink type, ink characteristics, ink colour, ink manufacturer). 

2.4 Operational procedure 
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The operational procedure can be divided into two parts: 

o Refilling of ink cartridges using the home refill station. 

o Refilling the ink reservoirs used in the refill station is discussed in Section 3. 

2.5 Refilling of ink cartridges using the home refill station 
5 Figure 359 shows the refill of ink cartridges in a home refill station. 

The following is a description for refilling of ink cartridges in the home refill station: 

o Load the ink cartridge into the cartridge interface unit of the ink refill unit. This will connect the QA 

Chip of the ink cartridge to the microprocessor assembly. It will also connect the ink output device of 

the ink refill unit to the ink cartridge. 
10 o The model number of the ink cartridge is read from the QA Chip by the microprocessor assembly 

controlling the ink refill units, 
o The microprocessor assembly will determine whether the ink refill unit is suitable for the ink cartridge 

model. 

o The refill option is selected on the microprocessor assembly through the user interface. The 
1 5 microprocessor assembly will then do the following: 

a. Read ink attributes (for example ink type, ink characteristics, ink colour, ink manufacturer etc) stored 
in the QA Chip of the ink cartridge. Refer to[l]. 

b. Compare the read ink attributes to the ink attribute list in the refill station. This may also require reading of 
the ink attributes stored in the QA Chip of the ink reservoirs in the refill unit. 

20 c. Only if Step b is successful, then do the following: 

i. Determine the amount of ink to be transferred by any or all of the following means, ensuring that the 
reservoir has enough ink for the transfer: 
o Fixed amount (e.g. based on a pre-programmed value ,cartridge model or reservoir type), 
o User-selectable amount. 
25 ii. Check the ink reservoir in the ink refill unit has adequate amount of ink to refill the ink cartridge 

iii. Decrement the amount of ink transferred from the QA Chip in the ink refill unit and increment the QA 
Chip in the ink cartridge with corresponding ink amount. 

iv. If incrementing of the QA Chip with ink amount is successful then a command is sent to the ink 
transfer mechanism to release the ink to the ink cartridge through the output device. 

30 3 Commercial refill station 
3.1 Functional Purpose 

The functional purpose of the commercial refill station is as follows: 
o To refill ink into ink cartridges that are taken to the refill station for refilling, 
o Multiple ink cartridges of different models can be refilled. 
35 o To ensure that the correct ink present in the refill station is transferred to the ink cartridge. 

o To ensure accurate measure of ink is transferred from the refilling station to the ink cartridge during 
refills. 
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• The refilling station provides all processing power required to perform refills of ink cartridges. 

3.2 Basic Components of the refill station 

Figure 360 shows the components of a commercial refill station. 

A commercial refill station will consist of multiple ink refill units controlled by a single microprocessor 
5 assembly. Each ink refill unit can refill a single ink cartridge at a time. 
Each ink refill unit will consist of the following sub units: 

• Ink reservoir unit 

• Switch unit 

• Ink transfer unit 

10 • Multiple cartridge interface unit 
3.2.1 

Ink reservoir unit 

Figure 361 shows the components of a ink reservoir unit. 
The ink reservoir unit will consist of the following: 
15 • Multiple ink reservoirs - which stores ink. Each refill device will allow ink reservoirs of various 

capacities. When the ink reservoir empties out, it is replaced by another reservoir containing more ink 

of the same or different type or refilled. Refer to Section 3.5. 

• A QA Chip and associated circuitry in each of the ink reservoirs - which stores the amount of ink in the 
reservoir along with the attributes of the ink in digital format. 

20 • The electrical connections of each of the QA Chips are connected to the microprocessor assembly. 

3.2.2 Switch unit 

This unit will switch the inks selected from different ink reservoirs to the ink transfer unit to be dispensed into 
ink cartridges. 

The switch unit will prevent mixing of any residual ink left in dispensing devices after each ink cartridge is 
25 refilled. 

3.2.3 Ink transfer unit 

The ink reservoir unit will consist of the following: 

• Ink output device from each ink reservoir. 

• An output ink transfer mechanism which controls the flow ink from the ink refill unit to the ink 
30 cartridge and is controlled by the microprocessor assembly. 

• Final ink output devices to the multiple cartridge interface assembly 

3.2.4 Multiple cartridge interface unit 

This unit will provide the physical interface to the ink cartridges. Each ink cartridge interface will hold 
cartridges of different physical dimensions. 
35 Each cartridge interface unit can provide an interface for about 20 physically different cartridges. 

The cartridge interface unit can removed from the ink refill unit and replaced with another interface unit to 
cater for other physically different cartridges. 
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3.2.5 Microprocessor assembly with a user interface 

The controls connections for the ink transfer mechanism and the electrical connections of the QA Chip are 
connected to the microprocessor assembly. The microprocessor assembly will oversee and control the refill 
process. 

The microprocessor assembly will communicate with a user interface to accept commands and provide 
responses for various refill operations. 

3.3 Ink cartridge description 

Ink cartridges which will be refilled in a commercial refill station must have a QA Chip storing the following 
components: 

o Ink amount remaining. 

o Ink attributes (for example - ink type, ink characteristics, ink colour, ink manufacturer). 

3.4 Operational procedure 

The operational procedure can be divided into two parts: 

o Refilling of ink cartridges using the commercial refill station. 

o Refilling the ink reservoirs used in the refill station is covered in Section 3.5. 

3.4.1 Refilling ink cartridges using the commercial refill station 

Figure 362 shows the refill of ink cartridges in a commercial refill station. 

The following is a description for refilling of ink cartridges in the commercial refill station: 

o Load the ink cartridge into the multiple cartridge interface unit of the ink refill unit. This will connect 

the QA Chip of the ink cartridge to the microprocessor assembly. It will also connect the ink output 

device of the ink refill unit to the ink cartridge, 
o The model number of the ink cartridge automatically is read from the QA Chip by the microprocessor 

assembly controlling the ink refill units, 
o The microprocessor assembly will determine whether the ink refill unit is suitable for the ink cartridge 

model. 

o The refill option is selected on the microprocessor assembly through the user interface. The 
microprocessor assembly will then do the following: 

a. Read ink attributes (for example ink type, ink characteristics, ink colour, ink manufacturer etc) stored 
in the QA Chip of the ink cartridge. Refer to[l]. 

b. Compare the read ink attributes to the ink attribute list in the refill station.This may also require reading of 
the ink attributes stored in the QA Chip of the ink reservoirs in the refill unit. 

C. Only if Step b is successful, then do the following: 

i. Detennine the amount of ink to be transferred by any or all of the following means, ensuring that the 

reservoir has enough ink for the transfer: 
o Fixed amount (e.g. based on a pre-programmed value, cartridge model or reservoir type), 
o User-selectable amount. 
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ii. The microprocessor assembly will calculate the cost of ink amount and interrogate the user for a 
payment method -credit card or cash. If credit card option is selected it will request a credit card number to 
be selected and interface to a payment system to complete the transaction before proceeding further. 

iii. Decrement the amount of ink transferred from the QA Chip in the ink refill unit and increment the QA 
5 Chip in the ink cartridge with corresponding ink amount. 

iv. If incrementing of the QA Chip with ink amount is successful then a command is sent to the ink 
transfer mechanism to release the ink to the ink cartridge through the output device. 

3.5 Refilling the ink reservoirs 

The ink reservoirs of any ink refill device can be refilled recursively by the procedure described in Section 
10 3 .4. 1 , the only exception being the ink cartridge replaced by the ink reservoir. 

3.6 Commercial refill station'for a production environment 

This refill station resembles a commercial refill station but fills multiple ink cartridges of the same type at the 
same time. This will serve as a filling station for new cartridges in a production environment. 
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LOGICAL INTERFACE SPECIFICATION FOR PREFERRED FORM OF OA CHIP 

1 Introduction 

This document defines the QA Chip Logical Interface , which provides authenticated manipulation of 
specific printer and consumable parameters. The interface is described in terms of data structures 
5 and the functions that manipulate them, together with examples of use. While the descriptions and 
examples are targetted towards the printer application, they are equally applicable in other domains. 

2 Scope 

The document describes the QA Chip Logical Interface as follows: 
10 o data structures and their uses (Section 5 to Section 9). 

o functions, including inputs, outputs, signature formats, and a logical implementation 
sequence (Section 10 to Section 30). 

o typical functional sequences of printers and consumables, using the functions and data 
structures of the interface (Section 31 to Section 32). 
1 5 The QA Chip Logical Interface is a logical interface, and is therefore implementation independent. 

Although this document does not cover implementation details on particular platforms, expected 

implementations include: 

o Software only 

o Off-the-shelf cryptographic hardware. 
20 o ASICs, such as SBR4320 [2] and SOPEC [3] for physical insertion into printers and ink 
cartridges 
o Smart cards. 

3 Nomenclature 
25 3.1 Symbols 

The following symbolic nomenclature is used throughout this document: 

Table 246. Summary of symbolic nomenclature 



Symbol 


Description 


Fpq 


Function F, taking a single parameter X 


F(X,Y] 


Function F, taking two parameters, X and Y 


X| Y 


X concatenated with Y 


XaY 


Bitwise X AND Y 


XvY 


Bitwise X OR Y (inclusive-OR) 


xe y 


Bitwise X XOR Y (exclusive-OR) 


^x 


Bitwise NOT X (complement) 
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X Y 


X is assianed the value Y 




The domain of assianment inouts to X is Y and 7 


X = Y 


Y ic on i ioI ir\ V 


y =t y 


Y iq not om iol tn Y 


ux 


Decrement X by 1 (floor 0) 


IfX 


Increment X by 1 (modulo register length) 


Erase X 


Erase Flash memory register X 


SetBitsfX, Y] 


Set the bits of the Flash memory register X based on Y 


Z <- ShiftRight[X, 
Y] 


Shift register X right one bit position, taking input bit 
from Y and placing the output bit in Z 


a.b 


Data field or member function 'b' in object a. 



3.2 Pseudocode 

3.2.1 Asynchronous 

The following pseudocode: 
5 var = expression 

means the var signal or output is equal to the evaluation of the expression. 

3.2.2 Synchronous 

The following pseudocode: 
var <— expression 

1 0 means the var register is assigned the result of evaluating the expression during this cycle. 

3.2.3 Expression 

Expressions are defined using the nomenclature in Table 246 above. Therefore: 

var = (a = b) 
is interpreted as the var signal is 1 if a is equal to b, and 0 otherwise. 
15 4 Terms 

4.1 QA Device and System 

An instance of a QA Chip Logical Interface (on any platform) is a QA Device. 
QA Devices cannot talk directly to each other. A System is a logical entity which has one or more 
QA Devices connected logically (or physically) to it, and calls the functions on the QA Devices. The 
20 system is considered secure and the program running on the system is considered to be trusted. 

4.2 Types of QA Devices 
4. 2. 1 Trusted QA Device 

The Trusted QA Device forms an integral part of the system itself and resides within the trusted 
environment of the system. It enables the system to extend trust to external QA Device s. The 
25 Trusted QA Device is only trusted because the system itself is trusted. 
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4.2.2 External untrusted QA Device 

The External untrusted QA Device is a QA Device that resides external to the trusted environment 
of the system and is therefore untrusted. The purpose of the QA Chip Logical Interface is to allow 
the external untrusted QA Devices to become effectively trusted. This is accomplished when a 
5 Trusted QA Device shares a secret key with the external untrusted QA Device, or with a Translation 
QA Device (see below). 

In a printing application external untrusted QA Devices would typically be instances of SBR4320 
implementations located in a consumable or the printer. 

4.2.3 Translation QA Device 

10 A Translation QA Device is used to translate signatures between QA Devices and extend effective 
trust when secret keys are not directly shared between QA Devices. 

The Translation QA Device must share a secret key with the Trusted QA Device that allows the 
Translation QA Device to effectively become trusted by the Trusted QA Device and hence trusted 
by the system. The Translation QA Device shares a different secret key with another external 
1 5 untrusted QA Device (which may in fact be a Translation QA Device etc). Although the Trusted QA 
Device doesn't share (know) the key of the external untrusted QA Device, signatures generated by 
that untrusted device can be translated by the Translation QA Device into signatures based on the 
key that the Trusted QA Device does know, and thus extend trust to the otherwise untrusted 
external QA Device. 

20 

In a SoPEC-based printing application, the Printer QA Device acts as a Translation QA Device 
since it shares a secret key with the SoPEC, and a different secret key with the ink carridges. 

4.2.4 Consumable QA Device 

25 A Consumable QA Device is an external untrusted QA Device located in a consumable. It typically 
contains details about the consumable, including how much of the consumable remains. 
In a printing application the consumable QA Device is typically found in an ink cartridge and is 
referred to as an Ink QA Device, or simply Ink QA since ink is the most common consumable for 
printing applications. However, other consumables in printing applications include media and 

30 impression counts, so consumable QA Device is more generic. 

4. 2. 5 Printer QA Device 

A Printer QA Device is an external untrusted device located in the printer. It contains details about 
the operating parameters for the printer, and is often referred to as a Printer QA. 
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4.2.6 Value Upgrader QA Device 

A Value Upgrader QA Device contains the necessary functions to allow a system to write an initial 
value (e.g. an ink amount) into another QA Device, typically a consumable QA Device . It also 
allows a system to refill/replenish a value in a consumable QA Device after use. 
5 Whenever a value upgrader QA Device increases the amount of value in another QA Device , the 
value in the value upgrader QA Device is correspondingly decreased. This means the value 
upgrader QA Device cannot create value - it can only pass on whatever value it itself has been 
issued with. Thus a value upgrader QA Device can itself be replenished or topped up by another 
value upgrader QA Device. 

10 

An example of a value upgrader is an Ink Refill QA Device, which is used to fill/refill ink amount in 
an Ink QA Device. 

4. 2. 7 Parameter Upgrader QA Device 

15 A Parameter Upgrader QA Device contains the necessary functions to allow a system to write an 
initial parameter value (e.g. a print speed) into another QA Device, typically a printer QA Device. It 
also allows a system to change that parameter value at some later date. 

A parameter upgrader QA Device is able to perform a fixed number of upgrades, and this number is 
20 effectively a consumable value. Thus the number of available upgrades decreases by 1 with each 
upgrade, and can be replenished by a value upgrader QA Device. 

4. 2. 8 Key programmer QA Device 

Secret batch keys are inserted into QA Devices during instantiation (e.g. manufacture). These keys 
25 must be replaced by the final secret keys when the purpose of the QA Device is known. The Key 

Programmer QA Device implements all necessary functions for replacing keys in other QA Devices. 

4.3 Signature 

Digital signatures are used throughout the authentication protocols of the QA Chip Logical Interface. 
30 A signature is produced by passing data plus a secret key through a keyed hash function. The 
signature proves that the data was signed by someone who knew the secret key. 
The signature function used throughout the QA Chip Logical Interface is HMAC-SHA1 [1], 

4.3.4 Authenticated Read 
35 This is a read of data from a non-trusted QA Device that also includes a check of the signature (see 
Section 4.3.3). When the System determines that the signature is correct for the returned data (e.g. 
by asking a trusted QA Device to test the signature) then the System is able to trust that the data 
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has not been tampered en route from the read, and was actually stored on the non-trusted OA 
Device. 

4.3.5 Authenticated Write 

5 An authenticated write is a write to the data storage area in a OA Device where the write request 
includes both the new data and a signature. The signature is based on a key that has write access 
permissions to the region of data in the OA Device, and proves to the receiving OA Device that the 
writer has the authority to perform the write. For example, a Value Upgrader Refilling Device is able 
to authorize a system to perform an authenticated write to upgrade a Consumable QA Device (e.g. 
10 to increase the amount of ink in an Ink QA Device). 

The QA Device that receives the write request checks that the signature matches the data (so that it 
hasn't been tampered with en route) and also that the signature is based on the correct 
authorization key. 

An authenticated write can be followed by an authenticated read to ensure (from the system's point 
15 of view) that the write was successful. 

4.3.6 Non-authenticated Write 

A non-authenticated write is a write to the data storage area in a QA Device where the write request 
includes only the new data (and no signature). This kind of write is used when the system wants to 
update areas of the QA Device that have no access-protection. 
20 The QA Device verifies that the destination of the write request has access permissions that permit 
anyone to write to it. If access is permitted, the QA Device simply performs the write as requested. 
A non-authenticated write can be followed by an authenticated read to ensure (from the system's 
point of view) that the write was successful. 

4.3.7 Authorized Modification of Data 

25 Authorized modification of data refers to modification of data via authenticated writes (see Section 
4.3.5). 
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Data Structures 
5 Summary 
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6 Instance/device identifier 

Each OA Device requires an identifier that allows unique identification of that OA Device by external 
systems, ensures that messages are received by the correct OA Device, and ensures that the same 
device can be used across multiple transactions. 

5 

Strictly speaking, the identifier only needs to be unique within the context of a key, since QA 
Devices only accept messages that are appropriately signed. However it is more convenient to have 
the instance identifier completely unique, as is the case with this design. 

1 0 The identifier functionality is provided by Chipld. 

6.1 ChipId 

Chipld is the unique 64-bit QA Device identifier. The Chipld is set when the QA Device is 
instantiated, and cannot be changed during the lifetime of the QA Device. 
15 A 64-bit Chipld gives a maximum of 1844674 trillion unique QA Devices. 

7 Key and key related data 

7.1 NUMKEYS, K, KEYlD, AND KEYLOCK 

Each QA Device contains a number of secret keys that are used for signature generation and 
20 verification. These keys serve two basic functions: 

o For reading, where they are used to verify that the read data came from the particular QA 
Device and was not altered en route. 

o For writing, where they are used to ensure only authorised modification of data. 

Both of these functions are achieved by signature generation; a key is used to generate a signature 
25 for subsequent transmission from the device, and to generate a signature to compare against a 

received signature. 

The number of secret keys in a QA Device is given by NumKeys. For this version of the QA Chip 
Logical Interface, NumKeys has a maximum value of 8. 

Each key is referred to as K, and the subscripted form K n refers to the nth key where n has the 
30 range 0 to NumKeys-1 (i.e. 0 to 7). For convenience we also refer to the nth key as being the key in 
the nth keyslot 

The length of each key is 160-bits. 160-bits was chosen because the output signature length from 
the signature generation function (HMAC-SHA1 ) is 160 bits, and a key longer than 160-bits does 
not add to the security of the function. 
35 The security of the digital signatures relies upon keys being kept secret. To safeguard the security 
of each key, keys should be generated in a way that is not deterministic. Ideally each key should be 
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programmed with a physically generated random number, gathered from a physically random 
phenomenon. Each key is initially programmed during OA Device instantiation. 
Since all keys must be kept secret and must never leave the QA Device, each key has a 
corresponding 31 -bit Keyld which can be read to determine the identity or label of the key without 
5 revealing the value of the key itself. Since the relationship between keys and Keylds is 1 :1 , a 

system can read all the Keylds from a QA Device and know which keys are stored in each of the 
keyslots. 

Finally, each keyslot has a corresponding 1-bit KeyLock status indicating whether the key in that 
slot/position is allowed to be replaced (securely replaced, and only if the old key is known). Once a 
1 0 key has been locked into a slot, it cannot be unlocked i.e. it is the final key for that slot. A key can 
only be used to perform authenticated writes of data when it has been locked into its keyslot (i.e. its 
KeyLock status = 1 ). Refer to Section 8.1 .1 .5 for further details. 

Thus each of the NumKeys keyslots contains a 160-bit key, a 31 -bit Keyld, and a 1-bit KeyLock. 
7.2 Common and Variant Signature Generation 
15 To create a digital signature, we pass the data to be signed together with a secret key through a key 
dependent one-way hash function. The key dependent one-way hash function used throughout the 
QA Chip Logical Interface is HMAC-SHA1[1]. 

Signatures are only of use if they can be validated i.e. QA Device A produces a signature for data 
and QA Device B can check if the signature was valid for that particular data. This implies that A 
20 and B must share some secret information so that they can generate equivalent signatures. 

Common key signature generation is when QA Device A and QA Device B share the exact same 
key i.e. key K A = key Kb. Thus the signature for a message produced by A using K A can be 
equivalents produced by B using K B . In other words SIGK/^message) = SIG K B(message) because 
key K A = key Kb. 

25 Variant key signature generation is when QA Device B holds a base key, and QA Device A holds a 
variant of that key such that K A = owf(K B ,U A ) where owf is a one-way function based upon the base 
key (Kb) and a unique number in A (U A ). Thus A can produce SIG^message), but for B to produce 
an equivalent signature it must produce K A by reading U A from A and using its base key Kb. K a is 
referred to as a variant key and K B is referred to as the base/common key. Therefore, B can 

30 produce equivalent signatures from many QA Devices, each of which has its own unique variant of 
K B . Since Chipld is unique to a given QA Device, we use that as U A . A one-way function is required 
to create K A from K B or it would be possible to derive Kb if K A were exposed. 
Common key signature generation is used when A and B are equally available 1 to an attacker. For 
example, Printer QA Devices and Ink QA Devices are equally available to attackers (both are 



1 The term "equally available" is relative. It typically means that the ease of availability of both are the effectively 
the same, regardless of price (e.g. both A and B are commercially available and effectively equally easy to 
come by). 
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commonly available to an attacker), so shared keys between these two devices should be common 
keys. 

Variant key signature generation is used when B is not readily available to an attacker, and A is 
readily available to an attacker. If an attacker is able to determine K A , they will not know K A for any 
5 other OA Device of class A, and they will not be able to determine K B . 

The OA Device producing or testing a signature needs to know if it must use the common or variant 
means of signature generation. Likewise, when a key is stored in a OA Device, the status of the key 
(whether it is a base or variant key) must be stored along with it for future reference. Both of these 
requirements are met using the Keyld as follows: 
1 0 The 31 -bit Keyld is broken into two parts: 

o A 30-bit unique identifier for the key. Bits 30-1 represents the Id. 

o A 1 -bit Variant Flag, which represents whether the key is a base key or a variant key. Bit 0 

represents the Variant Flag. 
Table 247 describes the relationship of the Variant Flag with the key. 
1 5 Table 247. Variant Flag representation 



value 


Key represented 


0 


Base key 


1 


Variant key 



7.2.1 Equivalent signature generation between QA Devices 

Equivalent signature generation between 4 QA Devices A, B, C and D is shown in Figure 363. Each 
20 device has a single key. Keyld. Id of all four keys are the same i.e Keyld A ./d = Keyld B ./d = Keyld c ./tf 
= Keyld D ./d. 

If Key\6 A .VariantFlag = 0 and Keyld B . VariantFlag = 0, then a signature produced by A, can be 
equivalents produced by B because K A = K B . 

If Keyld B . VariantFlag = 0 and Keyld c .VariantFlag = 1 , then a signature produced by C, is 
25 equivalents produced by B because Kc = f (K B , Chipld c ). 

If Keyld c . VariantFlag = 1 and Keyld D .VariantFlag = 1, then a signature produced by C, cannot be 
equivalents produced by D because there is no common base key between the two devices. 
If Keyld D . VariantFlag = 1 and Keyld A . VariantFlag = 0, then a signature produced by D, can be 
equivalents produced by A because Ko = f (K A , Chipld 0 ). 
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8 Operating and state data 

The primary purpose of a OA Device is to securely hold application-specific data. For example if the 
OA Device is an Ink OA Device it may store ink characteristics and the amount of ink-remaining. If 
5 the OA Device is a Printer OA Device it may store the maximum speed and width of printing. 
For secure manipulation of data: 

o Data must be clearly identified (includes typing of data), 
o Data must have clearly defined access criteria and permissions. 
The OA Chip Logical Interface contains structures to permit these activities. 
1 0 The QA Device contains a number of kinds of data with differing access requirements: 

o Data that can be decremented by anyone, but only increased in an authorised fashion e.g. 

the amount of ink-remaining in an ink cartridge, 
o Data that can only be decremented in an authorised fashion e.g. the number of times a 

Parameter Upgrader QA Device has upgraded another QA Device. 
15 o Data that is normally read-only, but can be written to (changed) in an authorised fashion e.g. 

the operating parameters of a printer, 
o Data that is always read-only and doesn't ever need to be changed e.g. ink attributes or the 

serial number of an ink cartridge or printer, 
o Data that is written by QACo/Silverbrook, and must not be changed by the OEM or end user 
20 e.g. a licence number containing the OEM's identification that must match the software in the 

printer. 

o Data that is written by the OEM and must not be changed by the end-user e.g. the machine 

number that filled the ink cartridge with ink (for problem tracking). 
8.1 M 

25 M is the general term for all of the memory (or data) in a QA Device. M is further subscripted to refer 
to those different parts of M that have different access requirements as follows: 
o M 0 contains all of the data that is protected by access permissions for key-based 

(authenticated) and non-key-based (non-authenticated) writes, 
o contains the type information and access permissions for the M 0 data, and has write-once 

30 permissions (each sub-part of can only be written to once) to avoid the possibility of 

changing the type or access permissions of something after it has been defined, 
o M 2 , M 3 etc., referred to as M 2 +. contains all the data that can be updated by anyone until the 

permissions for those sub-parts of M 2+ have changed from read/write to read-only. 
While all QA Devices must have at least M 0 and M 1t the exact number of memory vectors (M n s) 
35 available in a particular QA Device is given by NumVectors. In this version of the QA Chip 

Logical Interface there are exactly 4 memory vectors, so NumVectors = 4. 
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Each M n is 512 bits in length, and is further broken into 16 x 32 bit words. The Ah word of M n is 

referred to as M^i]. M n [0] is the least significant word of M n> and M n [15] is the most significant 
word of M n . 

8.1.1 M 0 and Mj 

5 In the general case of data storage, it is up to the external accessor to interpret the bits in any way it 
wants. Data structures can be arbitrarily arranged as long as the various pieces of software and 
hardware that interpret those bits do so consistently. However if those bits have value, as in the 
case of a consumable, it is vital that the value cannot be increased without appropriate 
authorisation, or one type of value cannot be added to another incompatible kind e.g. dollars should 
1 0 never be added to yen. 

Therefore M 0 is divided into a number of fields, where each field has a size, a position, a type and a 
set of permissions. M 0 contains all of the data that requires authenticated write access (one data 
element per field), and Mi contains the field information i.e. the size, type and access permissions 
for the data stored in M 0 . 

1 5 Each 32-bit word of M 1 defines a field. Therefore there is a maximum of 16 defined fields. M^O] 
defines field 0, M-i[1] defines field 1 and so on. Each field is defined in terms of: 
o size and position, to permit external accessors determine where a data item is 
o type, to permit external accessors determine what the data represents 
o permissions, to ensure approriate access to the field by external accessors. 

20 The 32-bit value M-,[n] defines the conceptual field attributes for field n as follows: 

With regards to consistency of interpretation, the type, size and position information stored in the 
various words of Mt allows a system to determine the contents of the corresponding fields (in M 0 ) 
held in the QA Device. For example, a 3-color ink cartridge may have an Ink OA Device that holds 
the amount of cyan ink in field 0, the amount of magenta ink in field 1 , and the amount of yellow ink 

25 in field 2, while another single-color Ink QA Device may hold the amount of yellow ink in field 0, 
where the size of the fields in the two Ink QA Devices are different. 

A field must be defined (in Mt) before it can be written to (in M 0 ). At QA Device instantiation, the 
whole of M 0 is 0 and no fields are defined (all of Mi is 0). The first field (field 0) can only be created 
by writing an appropriate value to M^O]. Once field 0 has been defined, the words of M 0 
30 corresponding to field 0 can be written to (via the appropriate permissions within the field definition 
M^O]). 

Once a field has been defined (i.e. M^n] has been written to), the size, type and permissions for 
that field cannot be changed i.e. is write-once. Otherwise, for example, a field could be defined 
to be lira and given an initial value, then the type changed to dollars. 
35 The size of a field is measured in terms of the number of consecutive 32-bit words it occupies. 
Since there are only 16 x 32-bit words in M 0 , there can only be 16 fields when all 16 fields are 
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defined to be 1 word sized each. Likewise, the maximum size of a field is 512 bits when only a 
single field is defined, and it is possible to define two fields of 256-bits each. 
Once field 0 has been created, field 1 can be created, and so on. When enough fields have been 
created to allocate all of M 0 , the remaining words in Mi are available for write-once general data 
5 storage purposes. 

It must be emphasised that when a field is created the permissions for that field are final and cannot 
be changed. This also means that any keys referred to by the field permissions must be already 
locked into their keyslots. Otherwise someone could set up a field's permissions that the key in a 
particular keyslot has write access to that field without any guarantee that the desired key will be 
1 0 ever stored in that slot (thus allowing potential mis-use of the field's value). 
8.1.1.1 Field Size and Position 

A field's size and position are defined by means of 4 bits (referred to as EndPos) that point to the 
least significant word of the field, with an implied position of the field's most significant word. The 
implied position of field O's most significant word is M 0 [15]. The positions and sizes of all fields can 
1 5 therefore be calculated by starting from field 0 and working upwards until all the words of M 0 have 
been accounted for. 

The default value of M^O] is 0, which means fieldO.endPos = 0. Since fieldO.startPos = 15, field 0 is 

the only field and is 16 words long. 

8.1.1.1.1 Example 
20 Suppose for example, we want to allocate 4 fields as follows: 

o field 0 :1 28 bits (4 x 32-bit words) 
field 1 : 32 bits (1 x 32-bit word) 

o field 2: 1 60 bits (5 x 32-bit words) 

o field 3: 1 92 bits (6 x 32-bit words) 
25 Field O's position and size is defined by M^O], and has an assumed start position of 15, which 

means the most significant word of field 0 must be in M 0 [1 5]. Field 0 therefore occupies M 0 [12] 

through to M 0 [15], and has an endPos value of 12. 

Field 1's position and size is defined by M-i[1], and has an assumed start position of 1 1 (i.e. 
M^OJ.endPos - 1 ). Since it has a length of 1 word, field 1 therefore occupies only M 0 [1 1] and its end 
30 position is the same as its start position i.e. its endPos value is 1 1 . 

Likewise field 2's position and size is defined by Mi [2], and has an assumed start position of 10 (i.e. 
M<i[1].endPos - 1). Since it has a length of 5 words, field 2 therefore occupies M 0 [6] through to 
M 0 [10] and and has an endPos value of 6. 

Finally, field 3's position and size is defined by M«i[3], and has an assumed start position of 5 (i.e. 
35 M^J.endPos - 1 ). Since it has a length of 6 words, field 3 therefore occupies M 0 [5] through to M 0 [0] 
and and has an endPos value of 0. 
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Since all 16 words of M 0 are now accounted for in the 4 fields, the remaining words of M t (i.e. 
though to M^IS]) are ignored, and can be used for any write-once (and thence read-only) data. 
Figure 365 shows the same example in diagramatic format. 

8.1.1.1.2 Determining the number of fields 

The following pseudocode illustrates a means of determining the number of fields: 
fieldNum FindNumFields (Ml ) 
startPos <— 15 
fieldNum <- 0 
While (fieldNum < 16) 

endPos <- Ml [fieldNum] .endPos 
If (endPos > startPos) 

# error in this field. . . so must be an attack 
attackDetected( ) # most likely clears all keys and data 
Endlf 
f ieldNum++ 
If (endPos = 0) 

return fieldNum # is already incremented 
Else 

startPos <- endPos - 1 # endpos must be > 0 
Endlf 
EndWhile 

# error if get here since 16 fields are consumed in 16 words at 
most 

attackDetected ( ) # most likely clears all keys and data 

8.1 .1 .1 .3 Determining the sizes of all fields 

The following pseudocode illustrates a means of determing the sizes of all valid fields: 
FindFieldSizes (Ml , f ieldSize [] ) 

numFields <- FindNumFields (Ml) # assumes that FindNumFields does 
all checking 
ntartPos <- 15 
fieldNum <— 0 

While (fieldNum < numFields) 

EndPos <r- Ml [fieldNum] .endPos 
f ieldSize [fieldNum] = startPos - endPos + 1 
startPos +- endPos - 1 # endpos must be > 0 
f ieldNum++ 
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Endwhile 

While (fieldNum < 16) 

f ieldSize [f ieldNum] <- 0 
f ieldNum++ 
5 EndWhile 

8.1.1.2 Field Type 

The system must be able to identify the type of data stored in a field so that it can perform 
operations using the correct data. For example, a printer system must be able identify which of a 
consumable's fields are ink fields (and which field is which ink) so that the ink usage can be 

1 0 correctly applied during printing. 

A field's type is defined by 1 5 bits. Table 332 in Appendix A lists the field types that are specifically 

required by the OA Chip Logical Interface and therefore apply across all applications. 

The default value of lA^O] is 0, which means fieldO.type = 0 (i.e. non-initialised). 

Strictly speaking, the type need only be interpreted by all who can securely read and write to that 

1 5 field i.e. within the context of one or more keys. However it is convenient if possible to keep all types 
unique for simplistic identification of data across all applications. 

In the general case, an external system communicating with a OA Device can identify the data 
stored in MO in the following way: 

o Read the Keyld of the key that has permission to write to the field. This will a give broad 
20 identification of the data type, which may be sufficient for certain applications. 

o Read the type attribute for the field to narrow down the identity within the broader context of 
the Keyld. 

For example, the printer system can read the Keyld to deduce that the data stored in a field can be 
written to via the HP_NetworkJnkRefill key, which means that any data is of the general ink 
25 category known to HP Network printers. By further reading the type attribute for the field the system 
can determine that the ink is Black ink. 

8.1.1.3 Field Permissions 

All fields can be ready by everyone. However writes to fields are governed by 1 3-bits of permissions 
that are present in each field's attribute definition. The permissions describe who can do what to a 
30 specific field. 

Writes to fields can either be authenticated (i.e. the data to be written is signed by a key and this 
signature must be checked by the receiving device before write access is given) or non- 
authenticated (i.e. the data is not signed by a key). Therefore we define a single bit (AuthRW) that 
specifies whether authenticated writes are permitted, and a single bit (NonAuthRW) specifying 
35 whether non-authenticated writes are permitted. Since it is pointless to permit both authenticated 
and non-authenticated writes to write any value (the authentciated writes are pointless), we further 
define the case when both bits are set to be interpreted as authenticated writes are permitted, but 



766 



non-authenticated writes only succeed when the new value is less than the previous value i.e. the 
permission is decrement-only. The interpretation of these two bits is shown in Table 249. 
Table 249. Interpretation of AuthRW and NonAuthRW 



NonAuthRW 


AuthRW 


Interpretation 


0 


0 


Read-only access (no-one can write to this field). 
This is the initial state for each field. At instantiation all of Mi is 0 
which means AuthRW and NonAuthRW are 0 for each field, and 
hence none of M 0 can be written to until a field is defined. 


0 


1 


Authenticated write access is permitted 
Non-authenticated write acecss is not permitted 


1 


0 


Authenticated write access is not permitted 
Non-authenticated write access is permitted (i.e. anyone can 
write to this field) 


1 


1 


Authenticated write access is permitted 
Non-authenticated write access is decrement-only. 



5 

If authenticated write access is permitted, there are 1 1 additional bits (bringing the total number of 
permission bits to 1 3) to more fully describe the kind of write access for each key. We only permit a 
single key to have the ability to write any value to the field, and the remaining keys are defined as 
being either not permitted to write, or as having decrement-only write access. A 3-bit KeyNum 
1 0 represents the slot number of the key that has the ability to write any value to the field (as long as 
the key is locked into its key slot), and an 8-bit KeyPerms defines the write permissions for the 
(maximum of) 8 keys as follows: 

o KeyPerms[n] = 0: The key in slot n (i.e. K n ) has no write access to this field (except when n = 
KeyNum). Setting KeyPerms to 0 prohibits a key from transferring value (when an amount is 
1 5 deducted from field in one OA Device and transferred to another field in a different QA 

Device) 

o KeyPerms[n] = 1 : The key in slot n (i.e. K n ) is permitted to perform decrement-only writes to 
this field (as long as Kn is locked in its key slot). Setting KeyPerms to 1 allows a key to 
transfer value (when an amount is deducted from field in one QA Device and transferred to 
20 another field in a different QA Device). 

The 13-bits of permissions (within bits 4-16 of M^n]) are allocated as follows: 
8.1.1.3.1 Example 1 

Figure 367 shows an example of permission bits for a field. 
In this example we can see: 
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o NonAuthRW = 0 and AuthRW = 1 , which means that only authenticated writes 
are allowed i.e. writes to the field without an appropriate signature are not 
permitted. 

o KeyNum = 3, so the only key permitted to write any value to the field is key 3 
5 (i.e. K 3 ). 

o KeyPerms[3] = 0, which means that although key 3 is permitted to write to this 

field, key 3 can't be used to transfer value from this field to other QA Devices, 
o KeyPerms[0,4,5,6,7] = 0, which means that these respective keys cannot write 

to this field. 

10 o KeyPerms[1,2] = 1 , which means that keys 1 and 2 have decrement-only access 

to this field i.e. they are permitted to write a new value to the field only when the 
new value is less than the current value. 
8.1.1.3.2 Example 2 

Figure 368 shows a second example of permission bits for a field. 
15 In this example we can see: 

o NonAuthRW and AuthRW = 1 , which means that authenticated writes are 
allowed and writes to the field without a signature are only permitted when the 
new value is less than the current value (i.e. non-authenticated writes have 
decrement-only permission). 
20 o KeyNum = 3, so the only key permitted to write any value to the field is key 3 

(i.e. K 3 ). 

© KeyPerms[3] = 1 , which means that key 3 is permitted to write to this field, and 

can be used to transfer value from this field to other QA Devices. 
o KeyPerms[0,4,5,6,7] = 0, which means that these respective keys cannot write 
25 to this field. 

o KeyPerms[1,2] = 1 , which means that keys 1 and 2 have decrement-only access 
to this field i.e. they are permitted to write a new value to the field only when the 
new value is less than the current value. 
8.1.1.4 Summary of Field attributes 
30 Figure 369 shows the breakdown of bits within the 32-bit field attribute value M^n]. 

Table 250 summarises each attribute. 
Table 250. Attributes for a field 



Attribute 


Sub-attribute name 


Size 
in bits 


Interpretation 


Type 


Type 


15 


Gives additional identification of the data 
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stored in the field within the context of the 
accessors of that field. 


Permissions 


KeyNum 


3 


The slot number of the key that has 
authenticated write access to the field. 




NonAuthRW 


1 


0 = non-authenticated writes are not 
permitted to this field. 

1 = non-authenticated writes are permitted 
to this field (see Table 249). 


AuthRW 


1 


0 = authenticated writes are not permitted 
to this field. 

1 = authenticated writes are permitted to 
this field. 


KeyPerms 


8 


Bitmap representing the write permissions 
for each of the keys when AuthRW = 1 . 
For each bit: 

0 = no write access for this key (except for 
key KeyNum) 

1 = decrement-only access is permitted for 
this key. 


Size and 
Position 


EndPos 


4 


The word number in M 0 that holds the Isw 
of the field. The msw is held in 
M1[fieldNum-1], where msw of field 0 is 
15. 



8,1.1.5 Permissions of 

Mi holds the field attributes for data stored in M 0 , and each word of IVh can be written to once only. 
It is important that a system can determine which words are available for writing. While this can be 
5 determined by reading Mi and determining which of the words is non-zero, a 16-bit permissions 
value Pi is available, with each bit indicating whether or not a given word in M n has been written to. 
Bit n of Pi represents the permissions for Mi[n] as follows: 

Table 251 . Interpretation of Pi[n] i.e. bit n of M/s permission 





Description 


0 


writes to M-,[n] are not permitted i.e. this word is now read-only 


1 


writes to Mitn] are permitted 



769 



Since Mi is write-once, whenever a word is written to in M 1f the corresponding bit of Pi is also 
cleared, i.e. writing to Mi[n] clears Pi[n]. 

Writes to M t [n] only succeed when all of Mi[0...n-1] have already written to (i.e. previous fields are 
defined) i.e. 

5 o Mi[0..n-1] must have already been written to (i.e. Pi[0..n-1] are 0) 
o Pi[n] = 1 (i.e. it has not yet been written to) 

In addition, if Mi[n-1].endPos * 0, the new Mi[n] word will define the attributes of field n, so must be 
further checked as follows: 

o The new Mi[n].endPos must be valid (i.e. must be less than Mi[n-1].endPos) 

1 0 © |f the new Mi[n].authRW is set, K key Num must be locked, and all keys referred to by 

the new Mi[n].keyPerms must also be locked. 

However if Mi[n-1].endPos = 0, then all of M 0 has been defined in terms of fields. Since enough 
fields have been created to allocate all of M 0 , any remaining words in Mi are available for write-once 
general data storage purposes, and are not checked any further. 
15 8.1.2 M2+ 

M 2 , M 3 etc., referred to as M 2 +, contains all the data that can be updated by anyone (i.e. no 
authenticated write is required) until the permissions for those sub-parts of M 2+ have changed from 
read/write to read-only. 

The same permissions representation as used for Mi is also used for M 2+ . Consequently P n is a 16- 
20 bit value that contains the permissions for M n (where n > 0). The permissions for word w of M n is 

given by a single bit P n [w]. However, unlike writes to M 1( writes to M 2+ do not automatically clear bits 
in P. Only when the bits in P 2+ are explictly cleared (by anyone) do those corresponding words 
become read-only and final. 
9 Session data 

25 Data that is valid only for the duration of a particular communication session is referred to as 

session data. Session data ensures that every signature contains different data (sometimes referred 
to as a nonce) and this prevents replay attacks. 
9.1 R 

R is a 160-bit random number seed that is set up (when the OA Device is instantiated) and from 
30 that point on it is internally managed and updated by the OA Device. R is used to ensure that each 
signed item contains time varying information (not chosen by an attacker), and each OA Devices R 
is unrelated from one OA Device to the next. 
This R is used in the generation and testing of signatures. 

An attacker must not be able to deduce the values of R in present and future devices. Therefore, R 
35 should be programmed with a cryptographically strong random number, gathered from a physically 
random phenomenon (must not be deterministic). 
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9.2 Advancing R 

The session component of the message must only last for a single session (challenge and 
response). 

The rules for updating R are as follows: 
5 © Reads of R do not advance R. 

o Everytime a signature is produced with R, R is advanced to a new random number, 
o Everytime a signature including R is tested and is found to be correct, R is advanced to a 
new random number. 

9.3 RlANDRe 

1 0 Each signature contains 2 pieces of session data i.e. 2 Rs: 

o One R comes from the QA Device issuing the challenge i.e. the challenger. This is so the 
challenger can ensure that the challenged QA Device isn't simply replaying an old signature 
i.e. the challenger is protecting itself against the challenged, 
o One R comes from the device responding to the challenge i.e. the challenged. This is so the 

1 5 challenged never signs anything that is given to it without inserting some time varying change 

i.e. protects the challenged from the challenger in case the challenger is actually an attacker 
performing a chosen text attack 
Since there are two Rs, we need to distinguish between them. We do so by defining each R as 
external (R E ) or local (R L ) depending on its use in a given function. For example, the challenger 

20 sends out its local R, referred to as R L . The device being challenged receives the challenger's R as 
an external R, i.e R E . It then generates a signature using its R|_ and the challenger's R E . The 
resultant signature and Rl are sent to the challenger as the response. The challenger receives the 
signature and R E (signature and Rl produced by the device being challenged), produces its own 
signature using R L (sent to the device being challenged earlier) and R E received, and compares that 

25 signature to the signature received as response. 
Signature functions 
10 Objects 
10.1 KeyRef 
10.1 .1 Object description 

30 Instead of passing keys directly into a function, a KeyRef (i.e. key reference) object is passed 
instead. A KeyRef object encapsulates the process by which a key is formed for common and 
variant forms of signature generation (based on the setting of the variables within the object). A 
KeyRef defines which key to use, whether it is a common or variant form of that key, and, if it is a 
variant form, the Chipld to use to create the variant. For more information about common and 

35 variant forms of keys, see Section 7.2. 

Users pass KeyRef objects in as input parameters to public functions of the QA Chip Logical 
Interface , and these KeyRefs are subsequently passed to the signature function (called within the 



771 



interface function). Note, however, that the method functions for KeyRef objects are not available 
outside the QA Chip Logical Interface. 
10.1 .2 Object variables 

Table 252 describes each of the variables within a KeyRef object. 
5 Table 252. Description of object variables for KeyRef object 



Parameter 


Description 


keyNum 


Slot number of the key to use as the basis for key formation 


useChipfd 


0 = the key to be formed is a common key (i.e. is the same as K key Num) 

1 = the key to be formed is a variant key based on K key Num 


Chipld 


When useChipId = 1 , this is the Chipld to be used to form the variant key (this 
will be the Chipld of the QA Device which stores the variant of K key Num) 
When useChipId = 0, chipld is not used 



10.1.3 Object Methods 
10.1.3.1 getKey 
1 0 public key getKey(void) 

10.1 .3.1 .1 Method description 

This method is a public method (public in object oriented terms, not public to users of the QA Chip 
Logical Interface) and is called by the GenerateSignature function to return the key for use in 
signature generation. 

15 If useChipfd is true, the formKeyVariant method is called to form the key using chipld and then 
return the variant key. If useChipId is false, the key stored in slot keyNum is returned. 

10.1.3.1.2 Method sequence 

The getKey method is illustrated by the following pseudocode: 
If (useChipId = 0) 
20 key <~ K keyNum 

Else 

key <- formKeyVariant { ) 
Endlf 

Return key 
25 10.1.3.2 formKeyVariant 

private key formKeyVariant (void) 
1 0.1 .3.2.1 Method description 

This method produces the variant form of a key, based on the K keyNum and chipld. As described in 
Section 7.2, the variant form of key KkeyNum is generated by owf (KkeyNum, chipld) where owf is a one- 
30 way function. 
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In addition, the time taken by owf must not depend on the value of the key i.e. the timing should be 
effectively constant. This prevents timing attacks on the key. 

At present, owf is SHA1 , although this still needs to be verified. Thus the variant key is defined to be 

SHA1(KKeyNum|chipld). 

5 1 0.1 .3.2.2 Method sequence 

The formKeyVariant method is illustrated by the following pseudocode: 

key <— SHA1 ( Kjceymim I chipld) # Calculation must take constant time 

Return key 
1 1 Functions 

1 0 Digital signatures form the basis of all authentication protocols within the OA Chip Logical Interface . 
The signature functions are not directly available to users of the QA Chip Logical Interface , since a 
golden rule of digital signatures is never to sign anything exactly as it has been given to you. 
Instead, these signature functions are internally available to the functions that comprise the public 
interface, and are used by those functions for the formation of keys and the generation of 
1 5 signatures. 

11.1 GenerateSignature 

Input: KeyRef, Data, Random 1, Random2 

Output: SIG 
Changes: None 
20 Availability: All devices 

11.1.1 Function description 

This function uses KeyRef to obtain the actual key required for signature generation, appends 
Randoml and Random2 to Data, and performs HMAC_SHA1[key, Data] to output a signature. 
HMAC_SHA1 is described in [1]. In addition, this operation must take constant time irrespective of 
25 the value of the key (see Section 10.1 .3.2 for more details). 

1 1 .1 .2 Input parameter description 

Table 253 describes each of the input parameters: 

Table 253. Description of input parameters for GenerateSignature 



Parameter 


Description 


KeyRef 


This is an instance of the KeyRef object for use by the GenerateSignature 
function. For common key signature generation: KeyRef.keyNum = Slot number 
of the key to be used to produce the signature. KeyRef.useChipId = 0 


For variant key signature generation: KeyRef.keyNum = Slot number of the key 
to be used for generating the variant key, where the var iant key is to be used to 
produce the signature KeyRef.useChipId = 1 KeyRef.chipId = Chipld of the QA 
Device which stores the variant of K Ke yRef.*eyA/i/m, and uses the variant key for 
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signature generation. 


Data 


Preformatted data to be signed. 

Random 1 and Random2 are appended to Data before the signature is generated 
to ensure that the signature is session based (applicable only to a single 
session). 


Random 1 


This is the session component from the OA Device that is responding to the 
challenge. 


Random! 


This is the session component from the QA Device that issued the challenge. 



11.1.3 Output parameter description 

Table 254 describes each of the output parameters. 

Table 254. Description of output parameters for GenerateSignature 

5 



Parameter 


Description 


SIG 


SIG = SIG key (Data | Random 1 | Random2) where key = 
KeyRef.getKeyQ 



1 1 .1 .4 Function sequence 

The GenerateSignature function is illustrated by the following pseudocode: 
key <— Key Re f .get Key () 

dataToBeSigned <- Data | Randoml | Random2 
10 SIG <r- HMAC_SHA1 (key, dataToBeSigned) # Calculation must take 

constant time 
Output SIG 
Return 

1 5 Basic Functions 
1 2 Definitions 

This section defines return codes and constants referred to by functions and pseudocode. 
12.1 ResultFlag 

The ResultFlag is a byte that indicates the return status from a function. Callers can use the value 
20 of ResultFlag to determine whether a call to a function succeeded or failed, and if the call failed, the 
specific error condition. 

Table 255 describes the ResultFlag values and the mnemonics used in the pseudocode. 
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Table 255. ResultFlag value description 



Mnemonic 


Description 


Possible causes 


Pass 


Function completed 
sucessfully 


Function successfully completed requested task. 


Fail 


General Failure 


An error occurred during function processing. 


oaaoig 


Signature mismatch 


Input signature didn't match the generated signature. 


Invalid Key 


KeyRef incorrect 


Input KeyRef. keyNum > 3. 


In valid Vector 


VectNum incorrect 


Input MvectNum> 3. 


InvalidPermissio 
n 


Permission not adqeuate to 
perform operation. 


Trying to perform a Write or WriteAuth with incorrect 
permissions. 


KeyAlreadyLocke 
d 


Key already locked . 


Key cannot be changed because it has already been 
locked. 



12.2 Constants 
5 Table 256 describes the constants referred to by functions and pseudocode. 

Table 256. Constants 



Definition 


Value \ ■ 


MaxKey 


NumKeys -1 (typically 
7) 


MaxM 


NumVectors -1 
(typically 3) 


MaxWordln 
M 


16-1 =15 



13 Getlnfo 

Input: None 

1 0 Output: ResultFlag, SoftwareReleaseldMajor, SoftwareReleaseldMinor, 

NumVec tors, NumKeys,Chipld 
DepthOfRollBackCache (for an upgrade device only) 
Changes None 
Availability: All devices 

15 1 3.1 Function description 

Users of OA Devices must call the Getlnfo function on each OA Device before calling any other 
functions on that device. 
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The Getinfo function tells the caller what kind of QA Device this is, what functions are available and . 
what properties this QA Device has. The caller can use this information to correctly call functions 
with appropriately formatted parameters. 

The first value returned, SoftwareReleaseldMajor, effectively identifies what kind of QA Device this 
5 is, and therefore what functions are available to callers. SoftwareReleaseldMinor tells the caller 
which version of the specific type of QA Device this is. The mapping between the 
SoftwareReleasetdMajor and type of device and their different functions is described in Table 258 
Every QA Device also returns NumVectors, NumKeys and Chipld which are required to set input 
parameter values for commands to the device. 
1 0 Additional information may be returned depending on the type of QA Device. The VarDataLen and 
VarData fields of the output hold this additional information. 
1 3.2 Output parameters 
Table 257 describes each of the output parameters. 

Table 257. Description of output parameters for Getinfo function 

15 



Parameter 


#bytes 


Description 


ResultFlag 




Indicates whether the function completed successfully or 
not. If it did not complete successfully, the reason for the 
failure is returned here. 
See Section 12.1. 


SoftwareReleaseldMa 
for 


1 


This defines the function set that is available on this QA 
Device. 


SoftwareReleaseldMi 
nor 


1 


This defines minor software releases within a major release, 
and are incremental changes to the software mainly to deal 
with bug fixes. 


NumVectors 


1 


Total number of memory vectors in this QA Device. 


NumKeys 


1 


Total number of keys in this QA Device. 


Chipld 


6 


This QA Device's Chipld 


VarDataLen 


1 


Length of bytes to follow. 


VarData 


(VarDataLen 
bytes) 


This is additional application specific data, and will be of 
length VarDataLen (i.e. may be 0). 



Table 258 shows the mapping between the SoftwareReleasetdMajor, the type of QA Device and 
the available device functions. 

Table 258. Mapping between SoftwareReleaseldMajor and available device 
20 functions 
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SoftwareReleasel 
d Major 


Device description 


Functions available 


1 


Ink or Printer OA Device 


Get Info 


Random 


Read 


Test 


Translate 


WriteMl+ 


WriteFields 


WriteFieldsAuth 


SetPerm 


ReplaceKey 


2 


Value Upgrader OA Device (e.g. Ink 
Refill OA Device) 


All functions in the Ink or Printer 
Device, plus: 


StartXfer 


XferAmount 


StartRollBack 


RollBackAmount 


3 


Parameter Upgrader QA Device 


All functions in the Ink or Printer 
device, plus: 


StartXfer 


XferField 


StartRollBack 


RollBackField 


4 


Key Replacement device 


All functions in the Ink or Printer 
Device, plus: 


GetProgramKey 


ReplaceKey - is different from the 
Ink or Printer device 


5 


Trusted device 


All functions in the Ink or Printer 
Device, plus: 


SignM 



Table 259 shows the VarData components for Value Upgrader and Parameter Upgrader QA 
Devices. 
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Table 259. VarData for Value and Parameter Upgrader OA Devices 



VarData 
Components 


Length in 
bytes 


Description 


DepthOfRollBackCac 
he 


1 


The number of datasets that can be 
accommodated 

in the Xfer Entry cache of the device. 



5 13.3 Function sequence 

The Getlnfo command is illustrated by the following pseudocode: 
Output Sof twareReleaseldMa j or 
Output Sof twareReleaseldMinor 
Output NumVectors 
10 Output NumKeys 

Output Chipld 

VarDataLen <- 1 # In case of an upgrade device 

Output DepthOfRollBackCache 

Return 

15 14 Random 

Input: None 

Output: R L 

Changes: None 

Availability: All devices 

20 The Random command is used by the caller to obtain a session component (challenge) for use in 
subsequent signature generation. 

If a caller calls the Random function multiple times, the same output will be returned each time. R L 
(i.e. this QA Device's R) will only advance to the next random number in the sequence after a 
successful test of a signature or after producing a new signature. The same Rl can never be used 
25 to produce two signatures from the same QA Device. 

The Random command is illustrated by the following pseudocode: 

Output R L 

Return 
15 Read 

30 Input: KeyRef, SigOnly, MSelect, KeyldSelect, WordSefect, R £ 

Output: ResultFlag, SelectedWordsOfSelectedMs, SefectedKeylds, R L , SIG 0il 



778 



Changes: R L 
Availability: All devices 

15.1 Function description 

The Read command is used to read data and keylds from a QA Device. The caller can specify 
5 which words from M and which Keylds are read. 

The Read command can return both data and signature, or just the signature of the requested data. 
Since the return of data is based on the caller's input request, it prevents unnecessary information 
from being sent back to the caller. Callers typically request only the signature in order to confirm 
that locally cached values match the values on the QA Device . 

1 0 The data read from an untrusted QA Device (A) using a Read command is validated by a trusted 
QA Device (B) using the Test command. The R L and SIG 0[A produced as output from the Read 
command are input (along with correctly formatted data) to the Test command on a trusted QA 
Device for validation of the signature and hence the data. S/G out can also optionally be passed 
through the Translate command on a number of QA Devices between Read and Test if the QA 

1 5 Devices A and B do not share keys. 

1 5.2 Input parameters 

Table 260 describes each of the input parameters: 

20 

Table 260. Description of input parameters for Read 



Parameter 


Description 


KeyRef 


For common key signature generation: KeyRef.keyNum = Slot 
number of the key to be used for producing the output signature. 
KeyRef.useChipId = 0 


No variant key signature generation required 


SigOnly 


Flag indicating return of signature and data. 0- indicates both the 
signature and data are to be returned. 1- indicates only the 
signature is to be returned. 


Mselect 


Selection of memory vectors to be read - each bit corresponding to 
a given memory vec tor (a maximum of NumVector bits) 0- 
indicates the memory vector must not be read. 1- indicates 
memory vector must be read. 


Key/dSelect 


Selection of Keylds to be read - each bit corresponds to a given 
Keyld (a maximum of NumKey bits). 0- indicates Keyld must not be 
read. 1- indicates Keyld must be read. 
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WordSelect 


Selection of words read from a desired M as requested in MSelect. 
Each WordSelect is 16 bits corresponding to each bit in MSelect. 
Each bit in the WordSelect indicates whether or not to read the 
corresponding word for the particular M. 0- indicates word must not 
be read. 1- indicates word must be read. 


Re 


External random value required for output signature generation (i.e 
the challenge). Re is obtained by calling the Random function on 
the device which will receive the *S7G out from the Read function. 



1 5.3 Output parameters 

Table 261 describes each of the output parameters. 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned here. 
See Section 12.1. 


SelectedWordsOfSelecte 
dMs 


Selected words from selected memory vectors as requested by 
MSelect and WordSelect. 


SelectedKeylds 


Selected Keylds as requested by KeyldSelect 


Rl 


Local random value added to the output signature(i.e S/G out ). Refer to 
Figure 370. 


SIG out 


SIGout = SIG Key Ref(data | Rl I Re) as shown in Figure 8. 
Refer to Section 10.1 .3.1 for details. 



15.3.1 SIG out 

Figure 370 shows the formatting of data for output signature generation. 
Table 262 gives the parameters included in SIG^ 

10 



Parameter 


Length in bits 


Value set internally 


Value set 
from Input 


RWSense 


3 


read constant = 000 
Refer to Section 1 5.3.1 .1 




MSelect 


4 




O 


KeyldSelect 


8 




o 



780 



Chipld 


48 


This OA Device's Chipld 




WordSelect 


16 per M 




• 


SelectedWordsOfSelecte 
dMs 


32 per word 


The appropriate words from the 
various Ms as selected by the 
caller 


• 


Rl 


160 


This QA Device's current R 




*e 


160 




• 



15.3.1.1 RWSense 

An RWSense value is present in the signed data to distinguish whether a signature was produced 
from a Read or produced for a WriteAuth. 
5 The RWSense is set to a read constant (000) for producing a signature from a read function. The 
RWSense is set to a write constant (001 ) for producing a signature for a write function. 
The RWSense prevents signatures produced by Read to be subsequently sent into a WriteAuth 
function. Only signatures produced with RWSense set to write (001 ), are accepted by a write 
function. 

10 1 5.4 Function sequence 

The Read command is illustrated by the following pseudocode: 

Accept input parameters- .KeyRef , SigOnly, MSelect, KeyldSelect 
# Accept input parameter WordSelect based on MSelect 

For i <— 0 to MaxM 
If (MSelect [i] = 1) 

Accept next WordSelect 
WordSelectTemp [i] <- WordSelect 
Endlf 
EndFor 
Accept R E 

Check range of KeyRef . keyNum 
If invalid 
25 ResultFlag «- InvalidKey 

Output ResultFlag 
Return 
Endlf 

30 UBuild SelectedWordsOfSelectedMs 
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20 



k <— 0 # k stores the word count for SelectedWordsOf SelectedMs 
SelectedWordsOf SelectedMs [k] <- 0 
For i<— 0 to 3 

If (MSelect [i] = 1) 
5 For j f-0 to MaxWordlnM 

If (WordSelectTemp [i] [j] =1) 

SelectedWordsOf SelectedMs [k] <- (Mi [ j ] ) 
k++ 
Endlf 

1 0 EndFor 
Endlf 
EndFor 

#Build SelectedKeylds 
15 1 <— 0# 1 stores the word count for SelectedKeylds 

SelectedKeylds [1] <- 0 
For i <— 0 to MaxKey 

If (KeyldSelect [i] = 1) 

SelectedKeylds [1] <- Keyld [i] 

20 i ++ 

Endlf 
EndFor 



25 ^Generate message for passing into the Generates ignature function 

data <r- (RWSense | MSelect | KeyldSelect | Chipld | WordSelect 

| SelectedWordsOf SelectedMs | SelectedKeylds) # Refer to 
Figure 370. 

^Generate Signature function 
30 SIG L <- GenerateSignature (KeyRef ,data # R L/ R E ) # See Section 11.1 

Update R L to R L2 
ResultFlag <- Pass 
Output ResultFlag 
If (SigOnly = 0) 

35 Output SelectedWordsOf SelectedMs, SelectedKeylds 

Endlf 
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Output R L , SIG L 
Return 
16 Test 

Input: KeyRef, DataLength, Data, R Et SIG E 

5 Output: ResultFlag 

Changes: Rl 

Availability: All devices except ink device 

16.1 Function description 

The Test command is used to validate data that has been read from an untrusted OA Device 
1 0 according to a digital signature SIG E . The data will typically be memory vector and Keyld data. SIG E 
(and its related R E ) is the most recent signature - this will be the signature produced by Read if 
Translate was not used, or will be the output from the most recent Translate if Translate was used. 
The Test function produces a local signature (SIG L = SIG key (Data|R E |R L ) and compares it to the input 
signature (SIG E ). If the two signatures match the function returns 'Pass', and the caller knows that 
1 5 the data read can be trusted. 

The key used to produce SIG L depends on whether SIG E was produced by a QA Device sharing a 
common key or a variant key. The KeyRef object passed into the interface must be set 
appropriately to reflect this. 

The Test function accepts preformatted data (as DataLength number of words), and appends the 
20 external /? E and local R L to the preformatted data to generate the signature as shown in Figure 371 . 

16.2 Input parameters 

Table 263 describes each of the input parameters. 

Table 263. Description of input parameters for Test 



Parameter 


Description 


KeyRef 


For testing common key signature: KeyRef.keyNum = Slot number of the key to 
be used for testing the signature. S/G E produced using K Ke yRef.keyNum by the 
external device. KeyRef. useChipId = 0 


For testing variant key signature: KeyRef.keyNum = Slot number of the key to be 
used for generating the variant key. S/G E produced using a variant of K Ke yRef.keyNum 
by the external device. KeyRef.useChipId = 1 KeyRefchipId = Chipld of the 
device which generated S/G E using a variant of KxeyRef-keyNum. 


DataLength 


Length of preformatted data in words. Must be non zero. 


Data 


Preformatted data to be used for producing the signature. 


Re 


External random value required for verifying the input signature. This will be the 
R from the input signature generator (i.e the device generating SIGe). 


SIG b 


External signature required for authenticating input data as shown in Figure 371 . 
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The external signature is generated either by a Read function or a Translate 
function. A correct S/G E = SIG Ke yRef(Data I Re I RJ. 



1 6.2.1 Input signature verification data format 

Figure 371 shows the formatting of data for input signature verification. 

The data in Figure 371 (i.e. not Re or RJ is typically output from a Read function (formatted as per 
5 Figure 370). The data may also be generated in the same format by the system from its cache as 
will be the case when it performs a Read using SigOnly = 1 . 
1 6.3 Output parameters 
Table 264 describes each of the output parameters. 

Table 264. Description of output parameters for Test 

10 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned here. 
See Section 12.1. 



1 6.4 Function sequence 

The Test command is illustrated by the following pseudocode: 
Accept input parameters-. KeyRef, DataLength 

15 

# Accept input parameter- Data based on DataLength 

For i f-0 to (DataLength - 1) 
Accept next word of Data 
20 EndFor 

Accept input parameters - R E , SIGe 

Check range of KeyRef . keyNum 
25 If invalid 

ResultFlag <- InvalidKey 

Output ResultFlag 

Return 
Endlf 

30 
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#Generate signature 

SIG L <— GenerateSignature (KeyRef , Data, R E , R L ) # Refer to Figure 371. 



#Check signature 
5 If (SIGl = SIG E ) 

Update R L to R L2 
ResultFlag <— Pass 
Else 

ResultFlag <- BadSig 
10 Endlf 

Output ResultFlag 
Return 
1 7 Translate 

Input: InputKeyRef, DataLength, Data, R E , SIG E , OutputKeyRef, R E2 

1 5 Output: ResultFlag, R L2 , SIG 0ut 

Changes: Rl 

Availability: Printer device, and possibly on other devices 

1 7. 1 Function description 

It is possible for a system to call the Read function on OA Device A to obtain data and signature, 
20 and then call the Test function on QA Device B to validate the data and signature. In the same way 
it is possible for a system to call the SignM function on a trusted QA Device B and then call the 
WriteAuth function on QA Device B to actually store data on B. Both of these actions are only 
possible when QA Devices A and B share secret key information. 

If however, A and B do not share secret keys, we can create a validation chain (and hence 
25 extension of trust) by means of translation of signatures. A given QA Device can only translate 

signatures if it knows the key of the previous stage in the chain as well as the key of the next stage 
in the chain. The Translate function provides this functionality. 

The Translate function translates a signature from one based on one key to one based another key. 
The Translate function first performs a test of the input signature using the InputKeyRef, and if the 
30 test succeeds produces an output signature using the OutputKeyRef. The Translate function can 
therefore in some ways be considered to be a combination of the Test and Read function, except 
that the data is input into the QA Device instead of being read from it. 

The InputKeyRef object passed into Translate must be set appropriately to reflect whether S/G e was 
produced by a QA Device sharing a common key or a variant key. 
35 The key used to produce output signature S/G^ depends on whether the translating device shares 
a common key or a variant key with the QA Device receiving the signature. The OutputKeyRef 
object passed into Translate must be set appropriately to reflect this. 
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Since the Translate function does not interpret or generate the data in any way, only preformatted 
data can be passed in. The Translate function does however append the external R E and local R L to 
the preformatted data for verifying the input signature, then advances R L to R L2 , and appends R L2 
and R E2 to the preformatted data to produce the output signature. This is done to protect the keys 
5 and prevent replay attacks. 

The Translate functions translates: 

o signatures for subsequent use in Test, typically originating from Read 

o signatures for subsequent use in WriteAuth, typically originating from SignM 

In both cases, preformatted data is passed into the Translate function by the system. For translation 
10 of data destined for Test, the data should be preformatted as per Figure 370 (all words except the 

Rs). For translation of signatures for use in WriteAuth, the data should be preformatted as per 

Figure 373 (all words except the Rs). 

1 7.2 Input parameters 

Table 265 describes each of the input parameters. 
1 5 Table 265. Description of input parameters for Translate 



Parameter 


Description 


InputKeyRef 


For translating common key Input signature: InputKeyRef.keyNum = Slot number 
of the key to be used for testing the signature. S/G E produced using 
KinputKeyRef.keyNum by the external device. InputKeyRef.useChipId = 0 . 


For translating variant key input signatures: InputKeyRef.keyNum = Slot number 
of the key to be used for generating the variant key. S/G E produced using a 
variant of KmputKeyRef.keyNum by the external device. InputKeyRef.useChipId =1 
InputKeyRef chipld = Chipld of the device which generated S/G E using a variant 

Of KmputKeyRef.keyNum- 


DataLength: 


Length of data in words. 


Data 


Data used for testing the input signature and for producing the output signature. 


Re 


External random value required for verifying input signature. This will be the R 
from the input signature generator (i.e device generating SIG^). 


S/G e 


External signature required for authenticating input data.The external signature is 
either generated by a Read function, a Xfer/Rollback function or a Translate 
function. A correct S/G E = SIG Key Ref(Data | R E | R L ). 


OutputKeyRe 
f 


For generating common key output signature: OutputKeyRefkeyNum = Slot 
number of the key for producing the output signature. SIGout produced using 
KoutputKeyRefkeyNum because the device receiving SIGout shares KoutputKeyRef.keyNum 
with the translating device. OutputKeyRefuseChipId = 0 
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For generating variant key output signature: OutputKeyRef.keyNum = Slot 
number of the key to be used for generating the variant key. SIGout produced 
using a variant of KoutputKeyRef.keyNum because the device receiving SIGout shares a 
variant of KoutputKeyRef.keyNum with the translating device. OutputKeyRef.useChipId = 
1 OutputKeyRef.chipfd = Chipld of the device which receives S/G ou t produced by 

a Variant Of KoutputKeyRef.keyNum- 


Re2 


External random value required for output signature generation. This will be the 
R from the destination of SIG OKA . Re2 is obtained by calling the Random function 
on the device which will receive the S/G out from the Translate function. 



1 7.2.1 Input signature verification data format 

This is the same format as used in the Test function. Refer to Section 16.2.1 . 
1 7.3 Output parameters 
5 Table 266 describes each of the output parameters. 

Table 266. Description of output parameters for Translate 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did not 
complete successfully, the reason for the failure is returned here. See Section 
12.1. 


Rl2 


Local random value used in output signature (i.e SIG 0{A ). 


S/Gout 


Output signature produced using OutputKeyRef.keyNum using the data format 
described in 
Figure 372. 

SIGout = SIGoutKeyReKData I Rl2 I Re2)Refer to Section 10.1.3.1for details. 



17.3.1 SIG out 

1 0 Figure 372 shows the data format for output signature generation from the Translate function. 
17.4 Function sequence 

The Translate command is illustrated by the following pseudocode: 

Accept input parameters - Input KeyRe f , DataLength 

15 # Accept input parameter- Data based on DataLength 

For i <— 0 to (DataLength - 1) 

Accept next Data 
EndFor 
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Accept input parameters - Re, SIG E OutputKeyRef, Re2 

Check range of InputKeyRef . keyNum and OutputKeyRef . keyNum 
If invalid 

ResultFlag <- Invalidkey 

Output ResultFlag 

Return 
Endlf 

^Generate Signature 

SIG L <r- Generates ignature (InputKeyRef , Data, R E , R L ) # Refer to Figure 
371 . 



^Validate input signature 
If (SIG L = SIG E ) 

Update R L to R^ 
Else 

ResultFlag <- BadSig 
Output ResultFlag 
Return 
Endlf 



^Generate output signature 

SIGout <— Generates ignature (OutputKeyRef, Data, R E/ R L ) # Refer to 

Figure 3 72. 

Update R L2 to R L3 

ResultFlag <— Pass 

Output ResultFlag, R^, SIGou t 

Return 

WriteM1 + 

Input: VectNum, WordSelect, MVal 

Output: ResultFlag 
Changes: M VectNum 
Availability: All devices 
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1 8.1 Function description 

The WriteM1+ function is used to update selected words of M1 +, subject to the permissions 
corresponding to those words stored in Pvectisium- 

Note: Unlike WriteAuth, a signature is not required as an input to this function. 

5 18.2 INPUT PARAMETERS 

Table 267 describes each of the input parameters. 

Table 267. Description of input parameters for WriteM1 + 



Parameter 


Description 


VectNum 


Number of the memory vector to be written. 
Must be in range 1 to (NumVectors -1) 


WordSelect 


Selection of words to be written. 

0- indicates corresponding word is not written. 

1- indicates corresponding word is to be written as per input. 
If WordSeiect[N bit] is set, then write to M Ve ctNum word N. 


MVal 


Multiple of words corresponding to the number of words 

selected for write. 

Starts with LSW of M Ve ctNum- 



1 0 Note: Since this function has no accompanying signatures, additional input parameter error 
checking is required. 
18.3 Output parameters 
Table 268 describes each of the output parameters. 

Table 268. Description of output parameters for WriteMI + 

15 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned here. 
See Section 12.1. 



1 8.4 Function sequence 

The WriteMI + command is illustrated by the following pseudocode: 
Accept input parameters VectNum, WordSelect 

20 

#Accept MVal as per WordSelect 

MValTemp[16] <~ 0 # Temporary buffer to hold MVal after being read 
For i 0 to MaxWordlnM # word 0 to word 15 
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If (WordSelect [i] = 1) 
Accept next MVal 

MValTemp[i] <— MVal # Store MVal in temporary buffer 
Endlf 
5 EndFor 

Check range of VectNum 
If invalid 

ResultFlag <- InvalidVector 
10 Output ResultFlag 

Return 
Endlf 

^Checking non authenticated write permission for M1 + 

15 

PermOK <- CheckM 1+ Perm (VectNum, WordSelect ) 

Writing M with MVal 

20 If (PermOK =1) 

WriteM (VectNum, MValTemp [] ) 
ResultFlag <— Pass 
Else 

ResultFlag <- Invalid Permission 
25 Endlf 

Output ResultFlag 
Return 

18.4.1 PermOK CheckMI +Perm ( VectNum, WordSelect) 

This function checks WordSelect against permission FvectNum for the selected word. 
30 For i <~ 0 to MaxWordlnM # word 0 to word 15 

If (WordSelect [i] =1) a ( PvectNum [ i 3 =0) # Trying to write a 
Readonly word 

Return PermOK<— 0 
Endlf 
35 EndFor 

Return PermOK<- 1 

18.4.2 WriteM(VectNum, MValTempQ) 
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This function copies MValTemp to M Ve ctNum- 
For i <— 0 to MaxWordlnM # Copying word from temp buff to M 
If (VectNum = 1) # If Ml 

PvectNum [ i ] <- 0 # Set permission to Readonly before writing 
5 Endlf 

MvectNumCi] <- MValTemp [i] # copy word 

buffer to M word 

Endlf 
EndFor 
10 19 WriteFields 

Input: FieldSelect, FieldVal 

Output: ResultFlag 
Changes: M VectNum 
Availability: All devices 

15 1 9.1 Function description 

The WriteFields function is used to write new data to selected fields (stored in MO). The write is 
carried out subject to the non-authenticated write access permissions of the fields as stored in the 
appropriate words of M1 (see Section 8.1 .1 .3). 

The WriteFields function is used whenever authorization for a write (i.e. a valid signature) is not 
20 required. The WriteFieldsAuth function is used to perform authenticated writes to fields. For 

example, decrementing the amount of ink in an ink cartridge field is permitted by anyone via the 

WriteFields, but incrementing it during a refill operation is only permitted using WriteFieldsAuth, 

Therefore WriteFields does not require a signature as one of its inputs. 

1 9.2 Input parameters 
25 Table 269 describes each of the input parameters. 

Table 269. Description of input parameters for WriteFields 



Parameter 


Description 


FieldSelect 


Selection of fields to be written. 

0- indicates corresponding field is not written. 

1- indicates corresponding field is to be written as per input. 
If FieldSelect [N bit] is set, then write to Field N of MO. 


FieldVal 


Multiple of words corresponding to the words for all selected fields. 
Since FieldO starts at M0[15], FieldVal words starts with MSW of 
iower field. 
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Note: Since this function has no accompanying signatures, additional input parameter error 
checking is required especially if the QA Device communication channel has potential for error. 
1 9.3 Output parameters 
Table 270 describes each of the output parameters. 
5 Table 270. Description of output parameters for WriteFields 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned here. 
See Section 12.1. 



19.4 Function sequence 

The WriteFields command is illustrated by the following pseudocode: 
10 Accept input parameters FieldSelect 

#Accept FieldVal as per FieldSelect into a temporary buffer 
MValTemp 

15 #Find the size of each FieldNum to accept FieldData 

FieldSize [16] <- 0 # Array to hold FieldSize assuming there are 16 
fields 

NumFields<— FindNumberOf Fields InMO (Ml, FieldSize) 

20 MValTemp [16] *- 0 # Temporary buffer to hold FieldVal after being 

read 

For i <-0 to NumFields 
If FieldSelect [i] = 1 

If i = 0 # Check if field number is 0 
25 PreviousFieldEndPos <— MaxWordlnM 

Else 

PreviousFieldEndPos «-Ml [i-1] .EndPos # position of the last 
word for the 

# previous 

30 field 

Endlf 

For j <r- (PreviousFieldEndPos -1) to Ml [FieldNum] . EndPos ( ) 
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MValTemp[j] = Next FieldVal word #Store FieldVal in 
MValTemp . 

EndFor 
Endlf 
EndFor 

#Check non- authenticated write permissions for all fields in 
FieldSelect 

PermOK <- CheckMONonAuthPerm ( FieldSelect , MValTemp , MO , Ml ) 
#Writing MO with MValTemp if permissions allow writing 

If (PermOK =1) 

WriteM ( 0 , MValTemp ) 

ResultFlag <— Pass 
Else 

ResultFlag <r- InvalidPermission 
Endlf 

Output ResultFlag 
Return 

1 9.4.1 NumFields FindNumOfFieldslnM0(M1 .FieldSizeQ) 

This function returns the number of fields in mo and an array FieldSize which stores the size of each 
field. 

CurrPos <r~ 0 
NumFields <— 0 

FieldSize [16] <— 0 # Array storing field sizes 

For FieldNum <— 0 to MaxWordlnM 

If (CurrPos = 0) # check if last field has reached 

Return FieldNum #FieldNum indicates number of fields in MO 
Endlf 

FieldSize [FieldNum] <- CurrPos - Ml [FieldNum] . EndPos 
If (FieldSize [FieldNum] < 0) 

Error # Integrity problem with field attributes 
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Return FieldNum # Lower MO fields are still valid but higher 
MO fields are 

# ignored 

Else 

CurrPos<— Ml [FieldNum] .EndPos 
Endlf 
EndFor 

19.4.2 WordBitMapForField GetWordMapForFieid(FieldNum,Ml) 

This function returns the word bitmap corresponding to a field i.e the field consists of which 
consecutive words. 

WordBitMapFor Field*— 0 

WordMapTemp <— 0 

PreviousFieldEndPos <— Ml [FieldNum -1] .EndPos # position of the 
last word for the 

# previous 

field 

For j <— (PreviousFieldEndPos +1) to Ml [FieldNum] .EndPos () 
# Set bit corresponding to the word position 
WordMapTemp <- SHIFTLEFT ( 1 , j ) 

WordBitMapForField <— WordMapTemp v WordBitMapForField 
EndFor 

Return WordBitMapForField 

19.4.3 PermOKCheckM0NonAuthPerm(FieldSelect,MValTempQ I M0,Ml) 

This functions checks non-authenticated write permissions for all fields in FieldSelect. 
PermOK CheckMONonAuthPerm ( ) 
FieldSize [16] <- 0 

NumFields <— FindNumOf FieldsInMO (FieldSize) 

# Loop through all fields in FieldSelect and check their 

# non- authenticated permission 
For i <- 0 to NumFields 

If FieldSelect [i] = 1 # check selected 

WordBitMapForField^ GetWordMapForField (i , Ml ) #get word 
bitmap for field 
PermOK 

<- CheckFieldNonAuthPerm ( i , WordBitMapForField, MValTemp , MO,) 
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# Check permission for field i in 

FieldSelect 

If (PermOK = 0) #Writing is not allowed, return if 

permissions for field 
5 # doesn't allow writing 

Return PermOK 
Endlf 
Endlf 
EndFor 

10 Return PermOK 

19.4.4 PermOK 

CheckFieldNonAuthPerm(FieldNum,WordBitMapForField, MValTempQ,M0) 
This function checks non authenticated write permissions for the field. 
DecrementOnly <— 0 
15 AuthRW <r- Ml [FieldNum] .AuthRW 

NonAuthRW <- Ml [FieldNum] .AuthRW 

If (NonAuthRW =0) # No NonAuth write allowed 

Return PermOK<— 0 
Endlf 

20 If ((AuthRW =0) a (NonAuthRW = 1))# NonAuthRW allowed 

Return PermOK<— 1 
Elself (AuthRW = 1) a (NonAuthRW = 1) # NonAuth DecrementOnly 
allowed 
PermOK 

25 <— ChecklnputDataForDecrementOnly (M0,MValTemp, WordBitMapForField) 

Return PermOK 
Endlf 

1 9.4.5 PermOK ChecklnputDataForDecrementOnly(M0,MValTempD,WordBitMapForField) 
This function checks the data to be written to the field is less than the current value. 

30 DecEncountered <— 0 

LessThanFlag <— 0 
EqualToFlag <— 0 
For i = MaxWordlnM to 0 

If (WordBitMapForField [i] = 1) # starting word of the field - 
35 starting at MSW 

# comparing the word of temp buffer with M0 current value 
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LessThanFlag <-MO[i] < MValTemp[i] 
EqualToFlag<- MO [i] = MValTemp [i] 

# current value is less or previous value has been decremented 
If (LessThanFlag =1) v (DecEncountered = 1) 
5 DecEncountered <— 1 

PermOK<— 1 

Return PermOK 

Elself (EqualToFlag *1) # Only if the value is greater than 
current and decrement not encountered in previous words 
10 PermOK<- 0 

Return PermOK 
Endlf 
Endlf 
EndFor 

15 



19.4.6 WriteM(VectNum, MValTempD) 

Refer to Section 18.4.2 for details. 
20 WriteFieldsAuth 
20 Input: KeyRef, FieldSelect, FieldVal, R E , SIG E 

Output: ResultFlag 

Changes: M0 and R L 

Availability: All devices 

20.1 Function description 

25 The WriteFieldsAuth command is used to securely update a number of fields (in M0 ). The write is 
carried out subject to the authenticated write access permissions of the fields as stored in the 
appropriate words of M1 (see Section 8.1 .1 .3). WriteFieldsAuth will either update all of the 
requested fields or none of them; the write only succeeds when all of the requested fields can be 
written to. 

30 The WriteFieldsAuth function requires the data to be accompanied by an appropriate signature 
based on a key that has appropriate write permissions to the field, and the signature must also 
include the local R (i.e. nonce/challenge) as previously read from this OA Device via the Random 
function. 

The appropriate signature can only be produced by knowing K KeyRef . This can be achieved by a call 
35 to an appropriate command on a QA Device that holds a key matching K KeyRef . Appropriate 
commands include SignM, XferAmount, XferField, StartXfer, and StartRollBack. 

20.2 Input parameters 
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Table 271 describes each of the input parameters for WriteAuth. 



Parameter 


Description 


KeyRef 


For common key signature generation: KeyRef.keyNum = Slot 
number of the key to be used for testing the input signature. 
KeyRef.useChipId - 0 


No variant key signature generation required 


FieldSelect 


Selection of fields to be written. 0- indicates corresponding field is 
not written. 1- indicates corresponding field is to be written as per 
input. If FieidSelect [N bit] is set, then write to Field N of MO. 


FieldVal 


Multiple of words corresponding to the total number of words for all 
selected fields. Since FieldO starts at M0[15], FieldVal words starts 
with MSW of lower field. 


RE 


External random value used to verify input signature. This will be 
the R from the input signature generator (i.e device generating 
SIGe). 


SIGE 


External signature required for authenticating input data. The 
external signature is either generated by a Translate or one of the 
Xfer functions. A correct S/G E = SIG Key Ref(clata | R E | R L ). 



5 20.2.1 Input signature verification data format 

Figure 373 shows the input signature verification data format for the WriteAuth function. 
Table 272 gives the parameters included in S/G E for Write Auth 



Parameter 


Length in bits 


Value set internally 


Value set 
from Input 


RWSense 


3 


write constant = 001 
Refer to Section 1 5.3.1 .1 




FieldNum 


4 




O 


ChipID 


48 


This OA Device's Chipld 




FieldData 


32 per word 




O 


Re 


160 




O 


Rl 


160 


random value from 
device 
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20.3 Output parameters 

Table 273 describes each of the output parameters. 

Table 273. Description of output parameters for WriteAuth 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did not 
complete successfully, the reason for the failure is returned here. See 
Section 12.1. 



20.4 Function sequence 

The WriteAuth command is illustrated by the following pseudocode: 

Accept input parameters -KeyRef, FieldSelect, 

#Accept FieldVal as per FieldSelect into a temporary buffer 
MValTemp 

#Find the size of each FieldNum to accept FieldData 

FieldSize [16] <— 0 # Array to hold FieldSize assuming there are 16 

fields 

NumFields<- FindNumberOf FieldsInMO (Ml , FieldSize) 

MValTemp[16] <— 0 # Temporary buffer to hold FieldVal after being 
read 

For i <— 0 to NumFields 

If i = 0 # Check if field number is 0 

PreviousFieldEndPos <— MaxWordlnM 
Else 

PreviousFieldEndPos <-Ml [i-1] .EndPos # position of the last 
word for the previous field 
Endlf 

For j <- (PreviousFieldEndPos -1) to Ml [FieldNum] . EndPos ( ) 

MValTemp[j] = Next FieldVal word #Store FieldVal in MValTemp . 
EndFor 
Endlf 
EndFor 
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Accept R E , SIGg 



Check range of KeyRef . keyNum 
If invalid range 
5 ResultFlag InvalidKey 

Output ResultFlag 

Return 
Endlf 

10 #Generate message for passing to Generates ignature function 

data <- (RWSense|FieldSelect|ChipId|FieldVal 

^Generate Signature 

SIG L <— Generates ignature ( KeyRef , data , R E/ R L ) # Refer to Figure 3 73. 

15 

# Check signature 
If (SIG L = SIGs) 

Update R L to R L2 
Else 

20 ResultFlag <— BadSig 

Output ResultFlag 
Return 
Endlf 

25 

#Check authenticated write permission for all fields in 
FieldSelect using KeyRef 

PermOK<- Che ckMOAuth Perm ( FieldSelect , MValTemp , MO , Ml , KeyRef ) 
If (PermOK = 1) 

30 WriteM(0 , MValTemp []) # Copy temp buffer to MO 

ResultFlag <- Pass 
Else 

ResultFlag <- InvalidPermission 
Endlf 

35 Output ResultFlag 

Return 

20.4.1 PermOK CheckMOAuthPermtFieldSelect.MValTempO.MO, Ml, KeyRef) 
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This functions checks non-authenticated write permissions for all fields in FieldSelect using KeyRef. 
PermOK CheckMONonAuthPerm ( ) 
FieldSize [16] <- 0 

NumFields «- FindNumOf FieldsInMO (FieldSize) 

# Loop through fields 
For i <— 0 to NumFields 

If FieldSelect [i] = 1 # check selected 

WordBitMapForField<- Ge tWordMap For Field (i , Ml ) #get word 
bitmap for field 

PermOK <- CheckAuthFieldPerm (i , WordBitMapForField, MValTemp, MO, 
KeyRef) 

# Check permission for field i in FieldSelect 
If (PermOK = 0) #Writing is not allowed, return if 

#permissions for field doesn't allow writing 
Return PermOK 
Endlf 
Endlf 
EndFor 

Return PermOK 

20.4.2 PermOK CheckAuthFieldPerm( FieldNum, WordMapForField.MValTempO, 
MO, KeyRef) 

This function checks authenticated permissions for an mo field using KeyRef 

(whether KeyRef has write permissions to the field). 
AuthRW <r~ Ml [FieldNum] .AuthRW 
KeyNumAtt <- Ml [FieldNum] .KeyNum 

If (AuthRW = 0) # Check whether any key has write permissions 

Return PermOK<— 0 # No authenticated write permissions 
Endlf 

# Check KeyRef has ReadWrite Permission to the field and it is 
locked 

If (KeyLock KeyNum = locked) a (KeyNumAtt = KeyRef . keyNum) 

Return PermOK<— 1 
Else # KeyNum is not a ReadWrite Key 
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KeyPerms <— Ml [FieldNum) . DOForKeys # Isolate KeyPerms for 
FieldNum 



# Cheese Decrement Only Permission for Key 
5 If (KeyPerms [KeyRef .keyNum] = 1) # Key is allowed to Decrement 

field 

PermOK 

<- ChecklnputDataForDecrementOnly (MO,MValTemp , WordMap For Field) 
Else # Key is a Readonly key 

10 PermOK<-0 
Endlf 
Endlf 

Return PermOK 

20.4.3 WordBitMapField GetWordMapForField(FieldNum,Ml) 
1 5 Refer to Section 1 9.4.2 for details. 

20.4.4 PermOK ChecklnputDataForDecrementOnly(M0,MValTempQ,WordMapForField) 

Refer to Section 1 9.4.5 for details. 

20.4.5 WriteM(VectNum, MValTempQ) 

Refer to Section 1 8.4.2 for details. 
20 21 SetPerm 

Input: VectNum, PermVal 

Output: ResultFlag, NewPerm 

Changes: P n 

Availability: All devices 

25 21 .1 Function description 

The SetPerm command is used to update the contents of P Ve ctNum (which stores the permission for 

M VectNum)- 

The new value for PvectNum is a combination of the old and new permissions in such a way that the 
more restrictive permission for each part of PvectNum is kept. 
30 MO's permissions are set by M1 therefore they can't be changed. 

M1 's permissions cannot be changed by SetPerm. M1 is a write-once memory vector and its 
permissions are set by writing to it. 

See Section 8.1 .1 .3 and Section 8.1 .1 .5 for more information about permissions. 
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21 .2 Input parameters 

Table 274 describes each of the input parameters for SetPerm. 



Parameter 


Description 


VectNum 


Number of the memory vector whose permission is being 
changed. 


PermVal 


Bitmap of permission for the corresponding Memory Vector. 



Note: Since this function has no accompanying signatures, additional input parameter error 

checking is required. 

21 .3 Output parameters 

Table 275 describes each of the output parameters for SetPerm. 

10 



Parameter 


Description 


ResuftFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned here. 
See Section 12.1. 


Perm 


If VectNum = 0, then no Perm is returned. 
If VectNum = 1, then old Perm is returned. 

If VectNum > 1 , then new Perm is returned after P V ectNum has been 
changed based on PermVal. 



21 .4 Function sequence 

The SetPerm command is illustrated by the following pseudocode: 
1 5 Accept input parameters- VectNum, PermVal 

Check range of VectNum 
If invalid 

ResultFlag <- InvalidVector 
20 Output ResultFlag 

Return 
Endlf 

If (VectNum =0) # No permssions for MO 
25 ResultFlag <— Pass 
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Output ResultFlag 
Return 
Elself (VectNum = l) 

ResultFlag <- Pass 
5 Output ResultFlag 

Output P x 
Return 
Elself (VectNum >1) 

# Check that only *RW parts are being changed 

10 # RW(1) -> RO(0), RO(0) ->RO(0), RW(1) ->RW(1) - valid change 

# RO(0) ->RW(1) - Invalid change 

# checking for change from Readonly to ReadWrite 
temp<— -PvectNum a PermVal 

If (temp =1 )# If invalid change is 1 
15 ResultFlag <- InvalidPermission 

Output ResultFlag 
Else 

PvectNum <- PermVal 
ResultFlag <— Pass 
20 Output ResultFlag 

Output PvectNum 

Endlf 



25 



Return 
Endlf 



22 ReplaceKey 

Input: KeyRef, Key Id, KeyLock, EncryptedKey,R E , SIG E 

Output: ResultFlag 

Changes: K KeyRe i keyNum and R L 

30 Availability: All devices 

22.1 Function description 

The ReplaceKey command is used to replace the contents of a non-locked keyslot, which means 
replacing the key, its associated keyld, and the lock status bit for the keyslot. A key can only be 
replaced if the slot has not been locked i.e. the KeyLock for the slot is 0. The procedure for 
35 replacing a key also requires knowledge of the value of the current key in the keyslot i.e. you can 
only replace a key if you know the current key. 
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Whenever the ReplaceKey function is called, the caller has the ability to make this new key the final 
key for the slot. This is accomplished by passing in a new value for the KeyLock flag. A new 
KeyLock flag of 0 keeps the slot unlocked, and permits further replacements. A new KeyLock flag of 
1 means the slot is now locked, with the new key as the final key for the slot i.e. no further key 
5 replacement is permitted for that slot. 
22.2 Input parameters 

Table 276 describes each of the input parameters for Replacekey. 



Parameter 


Description 


KeyRef 


For common key signature generation: KeyRef.keyNum = Slot number of the key 
to be used for testing the input signature, and will be replaced by the new key. 
r\^yr\GT.Us>&\^nipiu — u 


No variant key signature generation required 


Keyld 


Keyld of the new key. The LSB represents whether the new key is a variant or a 
common key. 


KeyLock 


Flag indicating whether the new key should be the final key for the slot or not. (1 
= final key, 0 = not final key) 


EncryptedKe 

y 


SIGkoi^ReIRl) © Knew where Koi d = KeyRef.getkey(). Refer to Section 10.1 .3.1 


RE 


External random value required for verifying input signature. This will be the R 
from the input signature generator (device generating S/G^). In this case the 
input signature is a generated by calling the GetProgramKey function on a Key 
Programming device. 


SIGE 


External signature required for authenticating input data and determining the new 
key from the EncryptedKey. 
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22.2.1 Input signature generation data format 

Figure 374 shows the input signature generation data format for the ReplaceKey function. 
Table 277 gives the parameters included in S/G E for ReplaceKey. 



Parameter 


Length in bits 


Value set internally 


Value set 
from Input 


Chipld 


48 


This QA Device's 
Chipld 




Keyld 


32 




O 


Re 


160 




o 


EncryptedKey 


160 




o 



5 

22.3 Output parameters 

Table 278 describes each of the output parameters for ReplaceKey. 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned here. 
See Section 12.1. 



22.4 Function sequence 

The ReplaceKey command is illustrated by the following pseudocode: 
Accept input parameters - KeyRef, Keyld, KeyLock, EncryptedKey, R 5 
SIGg 

15 

Check KeyRef . keyNum range 
If invalid 

ResultFlag «- InvalidKey 

Output ResultFlag 
20 Return 
Endlf 

#Generate message for passing to Generates ignature function 
data <r- ( Chipld | Keyld | KeyLock | R E | EncryptedKey) 

25 ^Generate Signature 
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SIG L <- GenerateSignature (KeyRef , data, Null, Null) # Refer to Figure 
374 . 



# Check if the key slot is unlocked 

If (KeyLock # unlock) 

ResultFlag <- KeyAlreadyLocked 

Output ResultFlag 

Return 
Endlf 

#Test SIGe 

If (SIG L # SIG E ) 

ResultFlag <r- BadSig 

Output ResultFlag 

Return 
Endlf 

SIG L <- GenerateSignature (Key, null, R E , R L ) 
Advance R L 

# Must Jbe atomic - must not be possible to remove power and have 
Keyld and KeyNum mismatched. Also preferable for KeyLock, although 
not strictly required. 

KKeyNum <~ SIG L © EncryptedKey 

KeyId KeyNl3m <- Keyld 

KeyLock KeyNum <r- KeyLock 

ResultFlag <— Pass 

Output ResultFlag 



Return 



SignM 



Input- 
Output: 
Changes: 
Availability: 



KeyRef, FieldSelect t FieldValLength, FieldVal, Chipld t R E 

ResultFlag, R L , SIG out 

Rl 

Trusted device only 
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23.1 Function description 

The SignM function is used to generate the appropriate digital signature required for the 
authenticated write function WriteFieldsAuth. The SignM function is used whenever the caller wants 
to write a new value to a field that requires key-based write access. 
5 The caller typically passes the new field value as input to the SignM function, together with the 

nonce (R E ) from the OA Device who will receive the generated signature. The SignM function then 
produces the appropriate signature S/G™,. Note that S/G ou/ may need to be translated via the 
Translate function on its way to the final WriteFieldsAuth QA Device. 

The SignM function is typically used by the system to update preauthorisation fields ( Section 
10 31.4.3). 

The key used to produce output signature S/G^ depends on whether the trusted device shares a 
common key or a variant key with the QA Device directly receiving the signature. The KeyRef object 
passed into the interface must be set appropriately to reflect this. 

23.2 Input parameters 

1 5 Table 279 describes each of the input parameters for SignM. 



Parameter 


Description 


KeyRef 


For generating common key output signature: 

Ref.keyNum = Slot number of the key for producing the output signature. 
SIG om produced using K K eyRef.keyNum because the device receiving 57G ou t shares 
K K eyRef.keyNumWith the trusted device. 
KeyRef.useChipId = 0 




For generating variant key output signature: 

KeyRef.keyNum = Slot number of the key to be used for generating the variant 
key. 

SIG out produced using a variant of KKeyRef.keyNum because the device receiving SIG out 
shares a variant of KKeyRef.keyNumWith the trusted device. 
KeyRef.useChipId = 1 

KeyRef.chipId = Chipld of the device which receives S/G out . 


FieldNum 


Field number of the field that will be written to. 


FieldDataLengt 
h 


The length of the FieldData in words. j 


FieldData 


The value that will be written to the field selected by FieldNum. 


Re 


External random value used in the output signature generation. 

R E is obtained by calling the Random function on the device, which will receive 

the SIG out from the SignM function, which in this case is the WriteAuth function or 
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the Translate function. 


Chipld 


Chip identifier of the device whose WriteAuth function will be called subsequently 
to perform an authenticated write to its FieldNum of mo. 



23.3 Output parameters 

Table 280 describes each of the output parameters. 
Table 280. Description of output parameters for SignM 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned here. 
See Section 12.1. 


Rl 


Internal random value used in the output signature. 


S/Gout 


SIGout = SIG Key Ref(data | R L | R E ) as shown in Figure 373. 

As per Figure 373, R E is actually R L and R L is R E with respect to device 

producing SIG out to be applied to WriteAuth function. 



23.3.1 SIG out 

Refer to Section 20.2.1 . 
23.4 Function sequence 

The SignM command is illustrated by the following pseudocode: 
Accept input parameters - KeyRef, FieldNum, FieldDataLength 

# Accept FieldData words 
For i = 0 to FieldValLength 

Accept next FieldData 
EndFor 

Accept Chipld, R E 

Check KeyRef . keyNum range 
If invalid 

ResultFlag <- InvalidKey 

Output ResultFlag 

Return 
Endlf 

#Generate message for passing into the Generates ignature function 
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data <r- (RWSense|FieldSelect|ChipId|FieldVal) 



^Generate Signature 



SIG, 



'out «- GenerateSignature (KeyRef , data, R L ,R E ) # Refer to Section 



5 



20.2.1. 



Advance R L to R^ 



ResultFlag <— Pass 



Output parameters ResultFlag, R L ,SIG ( 



r out 



Return 
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Functions on a 



Key programming OA Device 



24 



Concepts 



The key programming device is used to replace keys in other devices. 

The key programming device stores both the old key which will be replaced in the device being 
1 5 programmed, and the new key which will replace the old key in the device being programmed. The 
keys reside in normal key slots of the key programming device. 

Any key stored in the key programming device can be used as an old key or a new key for the 
device being programmed, provided it is permitted by the key replacement map stored within the 
key programming device. 
20 Figure 375 is representation of a key replacement map. The 1 s indicates that the new key is 

permitted to replace the old key. The 0s indicates that key replacement is not permitted for those 
positions. The positions in Figure 13 which are blank indicate a 0. 

According to the key replacement map in Figure 13, K 5 can replace K 1f Ke can replace K 3 , Kt, K 5 ,K 7 , 
K 3 can replace K 2 , Ko can replace K 2 , and K 2 can replace K6. No key can replace itself. 

25 Figure 375._ Key replacement map 

The key replacement map must be readable from an external system and must be updateable by 
an authenticated write. Therefore, the key replacement map must be stored in an mo field. This 
requires one of the keys residing in the key programming device to be have ReadWrite access to 
the key replacement map. This key is referred to as the key replacement map key and is used to 

30 update the key replacement map. 

There will one key replacement map field in a key programming device. 

No key replacement mappings are allowed to the key replacement map key because it should not 
be used in another device being programmed. To prevent the key replacement map key from being 
used in key replacement, in case the mapping has been accidentally changed, the key replacement 
35 map key is allocated a fixed key slot of 0 in all key programming devices. If a GetProgram function 
is invoked on the key programming device with the key replacement map key slot number 0 it 
immediately returns an error, even before the key replacement map is checked. 
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i 

i 

The keys Ko to K 7 in the key programming device are initially set during the instantiation of the key 
programming device. Thereafter, any key can be replaced on the key programming device by 
another key programming device If a key in a key slot of the key programming device is being 
replaced, the key replacement map for the old key must be invalidated automatically. This is done 
5 by setting the row and column for the corresponding key slot to 0 For example, if K, is replaced, 
then column 1 and row 1 are set to 0, as indicated in Figure 376. 

The new mapping information for is then entered by performing an authenticated write of the key 
replacement map field using the key replacement map key. 
24 .1 Key replacement map data structure 

10 As mentioned in Section 24, the key replacement map must be readable by external systems and 
must be updateable using an authenticated write by the key replacement map key. Therefore, the 
key replacement map is stored in an mo field of the key programming device. The map is 8 x8 bits 
in size and therefore can be stored in a two word field. The LSW of key replacement map stores the 
mappings for Ko - K 3 .The MSW of key replacement map stores the mappings for - K 7 . Referring 

15 to Figure 375, key replacement map LSW is 0x40092000 and MSW is 0x40224040. Referring to 
Figure 376, after Ki is replaced in the key programming device, the value of the key replacement 
map LSW is 0x40090000 and MSW is 0x40224040. 

The key replacement map field has an M1 word representing its attributes. The attribute setting for 
this field is specified in Table 281 . 
20 Table 281 . Key replacement map attribute setting 



Attribute 
name 


Value 


Explanation 


Type 


TYPE_KEY_MAP 

Refer to Appendix A. 


Indicates that the field value 
represents a key replacement map. 
Only one such field per key 
programming OA Device. 


KeyNum 


0 


Slot number of the key replacement 
map key. 


NonAuthRW 


0 


No non authenticated writes is 
permitted. j 


AuthRW 


1 


Authenticated write is permitted. 


KeyPerms 


0 


No Decrement Only permission for 
any key. 


EndPos 


Value such that field size is 2 
words 
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24.2 Basic scheme 

The Key Replacement sequence is shown Figure 377. 

Following is a sequential description of the transfer and rollback process: 

1 . The System gets a Random number from the OA Device whose keys are going to be 
5 replaced. 

2. The System makes a GetProgramKey Request to the Key Programming QA Device. The Key 
Programming QA Device must contain both keys for QA Device whose keys are being replaced - 
Old Keys which are the keys that exist currently (before key replacement), and the New Keys which 
are the keys which the QA Device will have after a successful processing of the ReaplceKey 

1 0 Request. The GetProgramKey Request is called with the Key number of the Old Key (in the Key 
Programming QA Device) and the Key Number of the New Key ( in the Key Programming QA 
Device), and the Random number from (1). The Key Programming QA Device validates the 
GetProgramKey Request based on the KeyRepfacement map, and then produces the necessary 
GetProgramKey Output. The GetProgramKey Output consists of the encrypted New Key 

1 5 (encryption done using the Old Key), along with a signature using the Old Key. 

3. The System then applies GetProgramKey Output to the QA Device whose key is being 
replaced, by calling the ReplaceKey function on it, passing in the GetProgramKey Output The 
ReplaceKey function will decrypt the encrypted New Key using the Old Key, and then replace its 
Old Key with the decrypted New Key. 

20 25 Functions 

25.1 GetProgamKey 



25.1.1 Function description 

The GetProgramKey works in conjunction with the ReplaceKey command, and is used to replace 
the specified key and its Keyld. This function is available on a key programming device and 
produces the necessary inputs for the ReplaceKey function. The ReplaceKey command is then run 
30 on the device whose key is being replaced. 

The key programming device must have both the old key and the new key programmed as its keys, 
and the key replacement map stored in one of its mo field, before GetProgramKey can be called on 
the device. 

Depending on the OldKeyRef object and the Ne wKeyRef object passed in, the GetProgramKey will 
35 produce a signature to replace a common key by a common key, a variant key by a common key, a 
common key by a variant key or a variant key by a variant key. 
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Input: 
Output: 
Changes: 
Availability: 



OldKeyRef, Chipld, R E , KeyLock, NewKeyRef 
ResultFlag, R^ Encrypted Key, KeyldOfNewKey, S/G ( 
Rl 

Key programming device 



'out 
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25.1 .2 Input parameters 

Table 282 describes each of the input parameters for GetProgramKey. 



Parameter 


Description 


OldKeyRef 


Old key is a common key: OldKeyRef. keyNum = Slot number of the old key in the Key 
Programming QA Device. The device whose key is being replaced, shares a common 
key KoidKeyRef.keyNumWith the key programming device. OldKeyRef.useChipId = 0 


Old key is a variant key KeyRef.keyNum = Slot number of the old keyin the Key 
Programming QA Device, that will be used to generate the variant key. The device 
whose key is being replaced, shares a variant of KowKeyRef keyNum with the key 
programming device. OldKeyRef.useChipId = 1 OldKeyRef.chipId = Chipld of the 
device whose variant of KoidKeyRef.keyNum key is being replaced. 


Chipld 


Chip identifier of the device whose key is being replaced. 


RE 


External random value which will be used in output signature generation. R E is obtained 
by calling the Random function on the device being programmed. This will also receive 
the SIGout from the GetProgramKey function. SIGout is passed in to ReplaceKey 
function. 


KeyLock 


Flag indicating whether the new key should be unlocked/locked into its slot. 


NewKeyRef 


New key is a common key: NewKeyRef.keyNum = Slot number of the new keyin the 
Key Programming QA Device. The device whose key is being replaced, will receive a 
common key K NewKeyRef.keyNum from the key pro gramming device. 
NewKeyRef. useChipId = 0 


NewKey is a variant key: NewKeyRef.keyNum = Slot number of the new key in the Key 
Programming QA Device, that will be used to generate the new variant key. The device 
whose key is being replaced, will receive a new key which is a variant of 
KNewKeyRef.keyNum from the key programming device. NewKeyRef useChipId =1 
NewKeyRef.chipId = Chipld of the device receiving a new key, the new key is a variant 

Of the KNewKeyRef.keyNum. 



5 
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25.1 .3 Output parameters 

Table 283 describes each of the output parameters for GetProgramKey. 



Parameter 


Description 


Kesuitriag 


Indicates whether the function completed successfully or not. If it did not | 
complete successfully, the reason for the failure is returned here. See 
Section 12.1 and Table 284 


Rl 


Internal random value used in the output signature. 


EncryptedKey 


SIGkowC^lIRe) © Knew 


KeyldOfNewKe 

y 


Keyld of the new key.The LSB represents whether the new key is a variant 
or a common key. 


S/Gout 


SIGout = SIG Ko id(data | R L | R E ) 
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Table 284. ResultFlag definitions for GetProgramKey 



Result Flag 


Description 


InvalidKeyReplacementMap 


Key replacement map field invalid or doesn't exist. 


KeyReplacementNotAllowed 


Key replacement not allowed as per key replacement map. 



25.1.3.1 SIG 0iA 

1 0 Figure 378 shows the output signature generation data format for the 

GetProgramKey function. 
25.1 .4 Function sequence 

The GetProgramKey command is illustrated by the following pseudocode: 
Accept input parameters - OldKeyRef, Chipld, R E , KeyLock, 
1 5 NewKeyRef 



# key replacement map key stored in KO , must not be used for key 
replacement 

20 If (OldKeyRef .keyNum = 0) v (NewKeyRef . keyNum = 0) 

ResultFlag <- Fail 
Output ResultFlag 
Return 
Endlf 

25 
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CheckRange (OldKeyRef . keyNum) 
If invalid 

ResultFlag <- InvalidKey 

Output ResultFlag 

Return 
Endlf 



CheckRange (NewKeyRef . keyNum) 
If invalid 

ResultFlag <- InvalidKey 

Output ResultFlag 

Return 
Endlf 



# Find MO words that represent the key replacement map 
WordSelectForKeyMapField <-Get WordSelectForKeyMapField (Ml) 
If (WordSelectForKeyMapField = 0) 

ResultFlag <- InvalidKeyReplacementMap 

Output ResultFlag 

Return 
Endlf 



#CheckMapPermlts key replacement 
ReplaceOK 

^-CheckMapPermits (WordSelectForKeyMapField, OldKeyNum, NewKeyNum) 
If (ReplaceOK = 0) 

ResultFlag <- KeyRepI ace m en tNotAI lowed 

Output ResultFlag 

Return 
Endlf 



#All checks are OK, now generate Signature with OldKey 
SIG L <- GenerateSignature (OldKeyRef , null , R L ,R E ) 
#Get new key 

KNewKey* - NewKeyRef . getKey ( ) 
#Generate Encrypted Key 
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EncryptedKey <- SIG L 0 K^Key 



#Set Jbase key or variant key - bit 0 of Keyld 
If (NewKeyRef .useChipId = 1) 
5 Keyld<- 0x0001 a 0x0001 

Else 

Keyld <- 0x0001 a 0x0000 
Endlf 

10 #Set the new key Keyld to the Keyld - bits 1-30 of Keyld 

KeyIdOfNewKey<-SHIFTLEFT (KeyldOf NewKey , 1) 
Keyld<- Keyld v Key IdOf NewKey 

#Set the KeyLock as per input - bit 31 of Keyld 
1 5 KeyLock*- SHIFTLEFT (KeyLock, 31) 

#KeyId<- Keyld v KeyLock 

^Generate message for passing- in to the Generates ignature function 
data <- Chipld | Keyld | R L | EncryptedKey 

^Generate output signature 

SIG out <r- Generates ignature (OldKeyRef , data, null # null) 
# Refer to Figure 378 
Advance R L to R L2 
ResultFlag <- Pass 

Output ResultFlag, R L ,SIG out , Keyld, EncryptedKey 
Return 

25. 1.4. 1 WordSelectForField GetWordSelectForKeyMapFieldftAl) 

This function gets the words corresponding to the key replacement map in M0. 
FieldSize [16] <- 0 # Array to hold FieldSize assuming there are 16 
fields 

NumFields <— FindNumberOf FieldsInMO (Ml , FieldSize) 

#Find the key replacement map field 
35 For i <— 0 to NumFields 

If (TYPE_KEY_MAP = Ml [i] .Type) # Field is key map field 
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25 



30 
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MapFieldNum <— i 
Return 
Endif 
EndFor 

5 

#Get the words corresponding to the key replacement map 
WordMapForField<- GetWordMapFor Field (MapFieldNum, Ml ) 
Return WordSelectForField 

25. 1.4.2 NumFields FindNumOfFieldslnMOftA 1 , FieldSizeQ) 
1 0 Refer to Figure 1 9.4.1 for details 

25. 1.4.3 WordMapForField GetWordMapForField(FieldNum,M 1 ) 

Refer to Section 1 9.4.2 for details. 

25.1.4.4 ReplaceOKCheckMapPermits(WordSelectForKeyMapField, OldKeyNum, 
NewKeyNum, MO) 

1 5 This function checks whether key replacement map permits key replacement. 

^Isolate KeyReplacementMap based on WordSelectForKeyMapField and MO 
KeyReplacementMap [64 bit] 

20 #JsoIate permission bit corresponding- for NewKeyNum in the map for 

OldKeyNm 

ReplaceOK <r- KeyReplacementMap [ (OldKeyNum x 8 + NewKeyNum) bit] 
Return ReplaceOK 
25.2 REPLACEKEY 

25 Input: KeyRef, Keyld, KeyLock, EncryptedKey,R E , SIG E 

Output: ResultFlag 
Changes: K KeyNum and R L 

A vailability: Key programming device 

25.2.1 Function description 

30 This function is used for replacing a key in a key programming device and is similar to the generic 
RepiaceKey function(Refer to Section 24), with an additional step of setting the KeyRef.keyNum 
column and KeyRef.keyNum row key replacement map to 0. 

25.2.2 Input parameters 

Refer to Section 22. 
35 25.2.3 Output parameters 

Refer to Section 22. 
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25.2.4 



Function sequence 

The ReplaceKey command is illustrated by the following pseudocode: 
Accept input parameters - KeyRef, Keyld, EncryptedKey , R E , SIGe 



^Generate message for passing into Generates ignature function 
data <- (Chipld | Keyld | R E | EncryptedKey) # Refer to Figure 3 74. 



# Validate KeyRef, and then verify signature 
Result Flag = Va 1 i da teKeyRef AndS ignature ( KeyRef , data , R E , R L ) 
If (ResultFlag * Pass) 
Output ResultFlag 
1 5 Return 
Endlf 



# Check if the key slot is unlocked 
20 Isolate KeyLock for KeyRef 

If(KeyLock = lock) 

ResultFlag <- KeyAlreadyLocked 
Output ResultFlag 
Return 
25 Endlf 

SIG L <- GenerateSignature ( Key, Null, R E ,R L ) 
Advance R L 



30 



# Find MO words that represent the key replacement map 
WordSelectForKeyMapField <-GetWordSelectForKeyMapField (Ml) 



# Set the bits corresponding to the KeyRef . keyNum row and column 
to 0 

# i.e invalidate the key replacement map for KeyRef . keyNum. 

35 #Must Jbe done before the key is replaced and must be atomic with 

key replacement. 
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SetFlag 

<- SetKeyMapForKeyNum (WordSelectForKeyMapField, KeyRef . keyNum, MO ) 
If (SetFlag = 1) 

# Must be atomic - must not be possible to remove power and have 
5 Keyld and 

KeyNum mismatched 
K K eyNum <- SIG L © EncryptedKey 
KeyId KeyNurn <- Keyld 
KeyLockKeyNun, <- KeyLock 
10 ResultFlag <— Pass 

Else 

ResultFlag <— Fail 
Endlf 

Output ResultFlag 
1 5 Return 

25. 2. 4. 1 WordSelectForField GetWordSelectForKeyMapFietd(M 1 ; 

Refer to Figure 25.1 .4.1 for details. 

25.2.4.2 SetFlag SetKeyMapForKeyNum(WordSefectForKeyMapField,KeyNum, MO) 

This function invalidates the key replacement map for KeyNum. 
20 ^Isolate KeyReplacementMap based on WordSelectForKeyMapField and 

MO 

KeyReplacementMap [64 bit] 

# Set KeyNum row (all bits) to 0 in the KeyReplacementMap 
25 For i = 0 to 7 

KeyReplacementMap [ (KeyNum x8 + i) bit] <— 0 
EndFor 



# Set KeyNum column to 0 in the KeyReplacementMap 
30 For i = 0 to 7 

KeyReplacementMap [ ( ix8 + KeyNum) bit] <- 0 
EndFor 
SetFlag 1 
Return SetFlag 
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Functions 
Upgrade device 
(Ink re/fill) 
26 Concepts 
5 26.1 Purpose 

In a printing application, an ink cartridge contains an Ink QA Device storing the ink-remaining values 
for that ink cartridge. The ink-remaining values decrement as the ink cartridge is used to print. 
When an ink cartridge is physically re/filled, the Ink QA Device needs to be logically re/filled as well. 
Therefore, the main purpose of an upgrade is to re/fill the ink-remaining values of an Ink QA Device 

10 in an authorised manner. 

The authorisation for a re/fill is achieved by using a Value Upgrader QA Device which contains all 
the necessary functions to re/write to the Ink QA Device. In this case, the value upgrader is called 
an Ink Refill QA Device, which is used to fill/refill ink amount in an Ink QA Device. 
When an Ink Refill QA Device increases (additive) the amount of ink-remaining in an Ink QA Device, 

1 5 the amount of ink-remaining in the Ink Refill QA Device is correspondingly decreased. This means 
that the Ink Refill QA Device can only pass on whatever ink-remaining value it itself has been 
issued with. Thus an Ink Refill QA Device can itself be replenished or topped up by another Ink 
Refill QA Device. 

The Ink Refill QA Device can also be referred to as the Upgrading QA Device, and the Ink QA 
20 Device can also be referred to as the QA Device being upgraded. 

The refill of ink can also be referred to as a transfer of ink, or transfer of amount/valu, or an 
upgrade. 

Typically, the logical transfer of ink is done only after a physical transfer of ink is successful. 

26.2 Requirements 

25 The transfer process has two basic requirements: 

o The transfer can only be performed if the transfer request is valid. The validity of the transfer 
request must be completely checked by the Ink Refill QA Device, before it produces the 
required output for the transfer. It must not be possible to apply the transfer output to the Ink 
QA Device, if the Ink Refill QA Device has been already been rolled back for that particular 

30 transfer. 

o A process of rollback is available if the transfer was not received by the Ink QA Device. A 
rollback is performed only if the rollback request is valid. The validity of the rollback request 
must be completely checked by the Ink Refill QA Device, before it adjusts its value to a 
previous value before the transfer request was issued. It must not be possible to rollback an 
35 Ink Refill QA Device for a transfer which has already been applied to the Ink QA Device i.e 

the Ink Refill QA Device must only be rolled back for transfers that have actually failed. 

26.3 Basic scheme 
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The transfer and rollback process is shown in Figure 379. 

Following is a sequential description of the transfer and rollback process: 

1 . The System Reads the memory vectors MO and M1 of the Ink OA Device. The output from 
the read which includes the MO and M1 words of the Ink OA Device, and a signature, is passed as 

5 an input to the Transfer Request It is essential that MO and M1are read together. This ensures that 
the field information for MO fields are correct, and have not been modified, or substituted from 
another device. Entire MO and M1 must be read to verify the correctness of the subsequent 
Transfer Request by the Ink Refill OA Device. 

2. The System makes a Transfer Request to the Ink Refill OA Device with the amount that must 
10 be transferred, the field in the Ink Refill OA Device the amount must be transferred from, and the 

field in Ink QA Device the amount must be transferred to. The Transfer Request also includes the 
output from Read of the Ink QA Device. The Ink Refill QA Device validates the Transfer Request 
based on the Read output, checks that it has enough value for a successful transfer, and then 
produces the necessary Transfer Output The Transfer Output typically consists of new field data for 
1 5 the field being refilled or upgraded, additional field data required to ensure the correctness of the 
transfer/rollback, along with a signature. 

3. The System then applies the Transfer Output to the Ink QA Device, by calling an 
authenticated Write function on it, passing in the Transfer Output The Write is either successful or 
not. If the Write is not successful, then the System will repeat calling the Write function using the 

20 same transfer output, which may be successful or not. If unsuccesful the System will initiate a 

roflback of the transfer. The roiiback must be performed on the Ink Refill QA Device, so that it can 
adjust its value to a previous value before the current Transfer Request was initiated. It is not 
necessary to perform a rollback immediately after a failed Transfer. The Ink QA Device can still be 
used to print, if there is any ink remaining in it. 

25 4. The System starts a rollback by Reading the memory vectors MO and M1 of the Ink QA 
Device. 

5. The System makes a StartRollBack Request to the Ink Refill QA Device with same input 
parameters as the Transfer Request and the output from Read in (4). The Ink Refill QA Device 
validates the StartRollBack Request based on the Read output, and then produces the necessary 

30 Pre-rollback output The Pre-rollback output consists only of additional field data along with a signa- 
ture. 

6. The System then applies the Pre-rollback Output to the Ink QA Device, by calling an 
authenticated Write function on it, passing in the Pre-rollback output. The Write is either successful 
or not. If the Write is not successful, then either (6), or (5) and (6) must be repeated. 

35 7. The System then Reads the memory vectors MO and M1 of the Ink QA Device. 

8. The System makes a RollBack Request to the Ink Refill QA Device with same input 
parameters as the Transfer Request and the output from Read (7). The Ink Refill QA Device 
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validates the RollBack Request based on the Read output, and then rolls back its field 
corresponding to the transfer. 
26.3.1 Transfer 

As we mentioned, the Ink OA Device stores ink-remaining values in its MO fields, and its 
5 corresponding words contains field information for its ink-remaining fields. The field information 
consists of the size of the field, the type of data stored in field and the access permission to the 
field. See Section 8.1 .1 for details. 

The Ink Refill OA Device also stores its ink-remaining values in its MO fields, and its coressponding 
Mi words contains field information for its ink-remaining fields. 

10 26.3.1.1 Authorisation 

The basic authorisation for a transfer comes from a key, which has authenticated ReadWrite 
permission (stored in field information as KeyNum) to the ink-remaining field (to which ink will be 
transferred) in the Ink OA Device. We will refer to this key as the refill key. The refill key must also 
have authenticated decrement-only permission for the ink-remaining field (from which ink will be 

1 5 transferred) in the Ink Refill OA Device. 

After validating the input transfer request, the Ink Refill QA Device will decrement the amount to be 
transferred from its ink-remaining field, and produce a transfer amount (previous ink-remaining 
amount in the Ink QA Device + transfer amount), additional field data, and a signature using the 
refill key. Note that the Ink Refill QA Device can decrement its ink-remaining field only if the refill key 

20 has the permission to decrement it. 

The signature produced by the Ink Refill QA Device is subsequently applied to the Ink QA Device. 
The Ink QA Device will accept the transfer amount only if the signature is valid. Note that the 
signature will only be valid if it was produced using the refill key which has write permission to the 
ink-remaining field being written. 

25 26.3.1.2 Data Type matching 

The Ink Refill QA Device validates the transfer request by matching the Type of the data in ink- 
remaining information field of Ink QA Device to the Type of data in ink-remaining information field of 
the Ink Refill QA Device. This ensures that equivalent data Types are transferred i.e 
Network_OEM1_infrared ink is not transferred to Network_OEM1_cyan ink. 

30 26.3.1.3 Addition validation 

Additional validation of the transfer request must also be performed before a transfer output is 
generated by the Ink Refill QA Device. These are as follows: 
o For the Ink Refill QA Device: 

1 . Whether the field being upgraded is actually present. 
35 2. Whether the field being upgraded can hold the upgraded amount, 
o For the Ink QA Device: 

1 . Whether the field from which the amount is transferred is actually present. 
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2. Whether the field has sufficient amount required for the transfer. 
26. 3.1.4 Rollback facilitation 

To facilitate a rollback, the Ink Refill OA Device will store a list of transfer requests processed by it. 
This list is referred to as the Xfer Entry cache. Each record in the list consists of the transfer 
5 parameters corresponding to the transfer request. 
26.3.2 Rollback 

A rollback request is validated by looking through the Xfer Entry of the Ink Refill OA Device and 
finding the request that should be rolled back. After the right transfer request is found the Ink Refill 
OA Device checks that the output from the transfer request was not applied to the Ink OA Device by 
1 0 comparing the current Read of the Ink OA Device to the values in the Xfer Entry cache, and finally 
rolls back its ink-remaining field (from which the ink was transferred) to a previous value before the 
transfer request was issued. 

The Ink Refill QA Device must be absolutely sure that the Ink QA Device didn't receive the transfer. 
This factor determines the additional fields that must be written along with transfer amount, and also 
1 5 the parameters of the transfer request that must be stored in the Xfer Entry cache to facilitate a 
rollback, to prove that the Printer QA Device didn't actually receive the transfer. 
26.3.2.1 Sequence fields 

The rollback process must ensure that the transfer output (which was previously produced) for 
which the rollback is being performed, cannot be applied after the rollback has been performed. 

20 How do we achieve this? There are two separate decrement-only sequence fields (SEQ_1 and 

SEQ_2) in the Ink QA Device which can only be decremented by the Ink Refill QA Device using the 
refill key. The nature of data to be written to the sequence fields is such that either the transfer 
output or the pre-rollback output can be applied to the Ink QA Device, but not both Le they must be 
mutually exclusive. Refer to Table 285 for details. 

25 Table 285. Sequence field data for Transfer and Pre-rollback 



Function 


Sequence Field data 
written to Ink QA Device 
SEQ_1 


SEQ_2 


Explanation 


Initialised 


OxFFFFFFFF 


OxFFFFFFFF 


Written using the sequence key 
which is different from the refill 
key 


Write using 

Transfer 

Output 


(Previous Value - 2) 

If Previous Value =intialised 

value then OxFFFFFFFD 


(Previous Value - 1 ) 
If Previous Value = 
intialised value 
then OxFFFFFFFE 


Written using the refill key using 
the refill key which has 
decrement-only 
permission on the fields. 
Value cannot be written if pre- 
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rollback 

output is already written. 


Write usiing 
Pre-rollback 


(Previous Value - 1 ) 

If Previous Value =intialised 

value 

then OxFFFFFFFE 


(Previous Value - 2) 
If Previous Value = 
intialised value 
then OxFFFFFFFD 


Written using the refill key using 
the refill key which has 
decrement-only 
permissionon the fields. 
Value can be written only if 
Transfer 

Output has not been written. 



The two sequence fields are initialised to OxFFFFFFFF using sequence key. The sequence key is 
different to the refill key, and has authenticated ReadWrite permission to both the sequence fields. 
The transfer output consists of the new data for the field being upgraded, field data of the two 
5 sequence fields, and a signature using the refill key. The field data for SEQ_1 is decremented by 2 
from the original value that was passed in with the transfer request. The field data for SEQ_2 is 
decremented by 1 from the original value that was passed in with the transfer request. 
The pre-rollback output consists only of the field data of the two sequence fields, and a signature 
using the refill key. The field data for SEQ_1 is decremented by 1 from the original value that was 
1 0 passed in with the transfer request. The field data for SEQ_2 is decremented by 2 from the original 
value that was passed in with the transfer request. 

Since the two sequence fields are decrement-only fields, the writing of the transfer output to QA 
Device being upgraded will prevent the writing of the pre-rollback output to QA Device being 
upgraded. If the writing of the transfer output fails, then pre-rollback can be written. However, the 

1 5 transfer output cannot be written after the pre-rollback has been written. 

Before a rollback is performed, the Ink Refill QA Device must confirm that the sequence fields was 
successfully written to the pre-rollback values in the Ink QA Device. Because the sequence fields 
are Decrement-Only fields, the Ink QA Device will allow pre-rollback output to be written only if the 
upgrade output has not been written. It also means that the transfer output cannot be written after 

20 the pre-rollback values have been written. 

26.3.2.1 .1 Field information of the sequence data field 

For a device to be upgradeable the device must have two sequence fields SEQ_1 and SEQ_2 
which are written with sequence data during the transfer sequence. Thus all upgrading QA devices, 
ink QA Devices and printer QA Devices must have two sequence fields. The upgrading QA Devices 
25 must also have these fields because they can be upgraded as well. 
The sequence field information is defined in Table 286. 

Table 286. Sequence field information 
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Attribute Name 


Value 


Explanation 


Type 


TYPE_SEQ_1 or TYPE_SEQ_2. 


See Appendix A for exact value. 


KeyNum 


Slot number of the sequence key. 


Only the sequence key has 
authenticated 

ReadWrite access to this field. 


Non Auth RW 
Perm 


0 


Non authenticated ReadWrite 
is not allowed to the field. 


Auth RW Perm 


1 


Authenticated (key based) ReadWrite 
access 

is allowed to the field. 


KeyPerm 


KeyPerms[KeyNum] = 0 


KeyNum is the slot number of the 
sequence key, 

which has ReadWrite permission to the 
field. 




KeyPerms[Slot number of the refill 
key] = 1 


Refill key can decrement the sequence 
field. 


KeyPerms[others= 0 ..7(except refill 
key)] = 0 


All other keys have Readonly access. 


End Pos 




Set as required. Size is typically 1 word. 



26.3.3 Upgrade states 

There are three states in an transfer sequence, the first state is initiated for every transfer, while the 
next two states are initiated only when the transfer fails. The states are - Xfer, StartRollback, and 
5 Rollback. 

26.3.3.1 Upgrade Flow 

Figure 380 shows a typical upgrade flow. 

26.3.3.2 Xfer 

This state indicates the start of the transfer process, and is the only state required if the transfer is 
1 0 successful. During this state, the Ink Refill OA Device adds a new record to its Xfer Entry cache, 
decrements its amount, produces new amount, new sequence data (as described in Section 
26.3.2.1) and a signature based on the refill key. 

The Ink OA Device will subsequently write the new amount and new sequence data, after verifying 
the signature. If the new amount can be successfully written to the Ink OA Device, then this will 
1 5 finish a successful transfer. 

If the writing of the new amount is unsuccessful (result returned is BAD SIG ), the System will re- 
transmit the transfer output to the Ink OA Device, by calling the authenticated Write function on it 
again, using the same transfer output. 
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If retrying to write the same transfer output fails repeatedly, the System will start the rollback 
process on Ink Refill OA Device, by calling the Read function on the Ink OA Device, and 
subsequently calling the StartRollBack function on the Ink Refill QA Device. After a successful 
rollback is performed, the System will invoke the transfer sequence again. 
5 26.3.3,3 StartRollBack 

This state indicates the start of the rollback process. During this state, the Ink Refill QA Device 
produces the next sequence data and a signature based on the refill key. This is also called a pre- 
rollback, as described in Section 26.3.2. 

The pre-rollback output can only be written to the Ink QA Device, if the previous transfer output has 
1 0 not been written. The writing of the pre-rollback sequence data also ensures, that if the previous 
transfer output was captured and not applied, then it cannot be applied to the Ink QA Device in the 
future. 

If the writing of the pre-rollback output is unsuccessful (result returned is BAD SIG ), the System will 
re-transmit the pre-rollback output to the Ink QA Device, by calling the authenticated Write function 
15 on it again, using the same pre-rollback output. 

If retrying to write the same pre-rollback output fails repeatedly, the System will call the 
StartRollback on the Ink Refill QA Device again, and subsequently calling the authenticated Write 
function on the Ink QA Device using this output. 
26.3,3.4 Rollback 

20 This state indicates a successful deletion (completion) of a transfer sequence. During this state, the 

Ink Refill QA Device verifies the sequence data produced from StartRollBack has been correctly 

written to Ink Refill QA Device, then rolls its ink-remaining field to a previous value before the 

transfer request was issued. 

26.3.4 Xfer Entry cache 
25 The Xfer Entry data structure must allow for the following: 

o Stores the transfer state and sequence data for a given transfer sequence. 

o Store all data corresponding to a given transfer, to facilitate a rollback to the previous value 
before the transfer output was generated. 

The Xfer Entry cache depth will depend on the QA Chip Logical Interface implementation. For some 
30 implementations a single Xfer Entry value will be saved. If the Ink Refill QA Device has no 

powersafe storage of Xfer Entry cache, a power down will cause the erasure of the Xfer Entry cache 

and the Ink Refill QA Device will not be able to rollback to a pre-power-down value. 

A dataset in the Xfer Entry cache will consist of the following: 

o Information about the QA Device being upgraded: 
35 a. Chipld of the device. 

b. FieldNum of the MO field (i.e what was being upgraded). 

o Information about the upgrading QA Device: 
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a. FieldNum of the MO field used to transfer the amount from. 
© XferVal - the transfer amount. 

o Xfer State- indicating at which state the transfer sequence is. This will consist of: 

a. State definition which could be one of the following: - Xfer, 
5 StartRollBack and complete/deleted. 

b. The value of sequence data fields SEQ_1 and SEQJ2. 
26.3.4.1 Adding new dataset 

A new dataset is added to Xfer Entry cache by the Xfer function. 

There are three methods which can be used to add new dataset to the Xfer Entry cache. The 
1 0 methods have been listed below in the order of their priority: 

1 . Replacing existing dataset in Xfer Entry cache with new dataset based on Chipld and 
FieldNum of the Ink QA Device in the new dataset. A matching Chipld and FieldNum could 
be found because a previous transfer output corresponding to the dataset stored in the Xfer 
Entry cache has been correctly received and processed by the Ink Refill QA Device, and a 

1 5 new transfer request for the same Ink QA Device, same field, has come through to the Ink 

Refill QA Device. 

2. Replace existing dataset cache with new dataset based on the Xfer State. If the Xfer State for 
a dataset indicates deleted (complete), then such a dataset will not be used for any further 
functions, and can be overwritten by a new dataset. 

20 3. Add new dataset to the end of the cache. This will automatically delete the oldest dataset 
from the cache regardless of the Xfer State. 
26.4 Different types of transfer 
There can be three types of transfer: 

o Peer to Peer Transfer - This transfer could be one of the 2 types described below: 
25 a. From an Ink Refill QA Device to a Ink QA Device. This is performed when the Ink QA Device 
is refilled by the Ink Refill QA Device, 
b. From one Ink Refill QA Device to another Ink Refill QA Device, where both QA Devices 
belong to the same OEM. This is typically performed when OEM divides ink from one Ink 
Refill QA Device to another Ink Refill QA Device, where both devices belong to the same 
30 OEM 

o Heirachical Transfer- This is a transfer from one Ink Refill QA Device to another Ink Refill QA 
Device, where the QA Devices belong to different organisation, say ComCo and OEM. This is 
typically performed when ComCo divides ink from its refill device to several refill devices 
belonging to several OEMs. 
35 Figure 381 is a representation of various authorised ink refill paths in the printing system. 

26.4.1 Hierarchical transfer 
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Referring to Figure 381 , this transfer is typically performed when ink is transferred from ComCo's 
Ink Refill OA Device to OEM's Ink Refill OA Device, or from QACo's Ink Refill OA Device to 
ComCo's Ink Refill OA Device. 
26. 4.1.1 Keys and access permission 
5 We will explain this using a transfer from ComCo to OEM. 

There is an ink-remaining field associated with the ComCo's Ink Refill QA Device. This ink- 
remaining field has two keys associated with: 

o The first key transfers ink to the device from another refill device (which is higher in the 
heirachy), fills/refills (upgrades) the device itself. This key has authenticated ReadWrite 
1 0 permission to the field. 

o The second key transfers ink from it to other devices (which are lower in the heirachy), 
fills/refills (upgrades) other devices from it. This key has authenticated decrement-only 
permission to the field. 

There is an ink-remaining field associated with the OEM's Ink refill device. This ink-remaining field 

1 5 has a single key associated with: 

© This key transfers ink to the device from another refill device (which is higher or at 

the same level in the hierarchy), fills/refills (upgrades) the device itself, and additionally transfers ink 
from it to other devices (which are lower in the heirachy), fills/refills (upgrades) other devices from it. 
Therefore, this key has both authenticated ReadWrite and decrement-only permission to the field. 

20 For a successful transfer ink from ComCo's refill device to an OEM's refill device, the ComCo's refill 
device and the OEM's refill device must share a common key or a variant key. This key is fiil/refiil 
key with respect to the OEM's refill device and it is the transfer key with respect to the ComCo's 
refill device. 

For a ComCo to successfully fill/refill its refill device from another refill device (which is higher in the 
25 heirachy possibly belonging to the QACo), the ComCo's refill device and the QACo's refill device 

must share a common key or a variant key. This key is fiii/refill key with respect to the ComCo's refill 
device and it is the transfer key with respect to the QACo's refill device. 
26.4.1 .1 .1 Ink - remaining field information 

Table 287 shows the field information for an M0 field storing logical ink-remaining amounts in the 
30 refill device and which has the ability to transfer down the heirachy. 



Attribute Name 


Value 


Explanation 


Type 


For e.g - 

TYPE_HIGHQUALITY_BLACKJNK a 


Type describing the logical ink stored in 
the ink-remaining field in the refill device. 


KeyNum 


Slot number of the refill key. 


Only the refill key has authenticated 
ReadWrite access to this field. 
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Non Auth RW 
Perm b 


0 


Non authenticated ReadWrite 
is not allowed to the field. 


Auth RW Perm 0 


1 


Authenticated (key based) ReadWrite 
access 

is allowed to the field. 


KeyPerm 


KeyPerms[KeyNum] = 0 


KeyNum is the slot number of the re/7// 
key, 

which has ReadWrite permission to the 
field. 




KeyPerms[Slot Num of transfer key] = 1 


Transfer key can decrement the field. 


KeyPerms[others= 0..7(except transfer 
key)] = 0 


All other keys have Readonly access. 


End Pos 


Set as required. 


Depends on the amount of logical ink the 
device can store and storage resolution - 
i.e in picolitres or in microlitres. 



a. This is a sample type only and is not included in the Type Map in Appendix A. 

b. Non authenticated Read Write permission. 

c. Authenticated Read Write permission. 
5 26.4.2 Peer to Peer transfer 

Referring to Figure 381 , this transfer is typically performed when ink is transferred from OEM's Ink 
Refill Device to another Ink Refill Device belonging to the same OEM, or OEM's Ink Refill Device to 
Ink Device belonging to the same OEM. 
26. 4. 2. 1 Keys and access permission 
1 0 There is an ink-remaining field associated with the refill device which transfers ink amounts to other 
refill devices (peer devices), or to other ink devices. This ink-remaining field has a single key 
associated with: 

o This key transfers ink to the device from another refill device (which is higher or at the same 
level in the heirachy), fills/refills (upgrades) the device itself, and additionally transfers ink 
1 5 from it to other devices (which are lower in the heirachy), fills/refills (upgrades) other devices 

from it. 

This key is referred to as the fill/refill key and is used for both fill/refill and transfer. Hence, this key 
has both ReadWrite and Decrement-Only permission to the ink-remaining field in the refill device. 
26.4.2.1 .1 Ink-remaining field information 
20 Table 288 shows the field information for an M0 field storing logical ink-remaining amounts in the 
refill device with the ability to transfer between peers. 
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Attribute Name 


Value 


Explanation 


Type 


For e.g - 

TYPE_HIGHQUALITY_BL 
ACKJNK 3 


Type describing the logical ink stored in the ink- 
remaining field 
in the refill device. 


KeyNum 


Slot number of the refill 
key. 


Only the refill key has authenticated 
ReadWrite access to this field. 


Non Auth RW 
Perm b 


0 


Non authenticated ReadWrite 
is not allowed to the field. 


Auth RW Perm c 


1 


Authenticated (key based) ReadWrite access 
is allowed to the field. 


KeyPerm 


KeyPerms[KeyNum] = 1 


KeyNum is the slot number of the refill key, 

which has ReadWrite and Decrement permission to 

the field. 




KeyPerms[others= 0 
..7(except KeyNum)] = 0 


All other keys have Readonly access. 


End Pos 


Set as required. 


Depends on the amount of logical ink the device 
can store 

and storage resolution - Le in picolitres or in 
microlitres. 



a. This is a sample type only and is not included in the Type Map in Appendix A. 

b. Non authenticated Read Write permission. 

c. Authenticated Read Write permission. 
27 Functions 

27.1 XferAmount 

Input: KeyRef, M0 OfExternal, m OfExternal, Chipld, FieldNumL, 

FieldNumE, XferValLength, XferVal, InputParameterCheck 
(optional), R E/ S/G E , Re2 
Output: ResultFlag t FieldSelect f FieldVal f R^, S/G^ 

Changes: M0 and R L 

Availability Ink refill QA Device 
27 A .1 Function description 

The XferAmount function produces data and signature for updating a given M0 field. This data and 
signature when applied to the appropriate device through the WriteFieldsAuth function, will update 
the mo field of the device. 
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The system calls the XferAmount function on the upgrade device with a certain XferVal, this XferVal 
is validated by the XferAmount function for various rules as described in Section 27.1 .4, the function 
then produces the data and signature for the passing into the WriteFie/dsAuth function for the 
device being upgraded. 

5 The transfer amount output consists of the new data for the field being upgraded, field data of the 
two sequence fields, and a signature using the refill key. When a transfer output is produced, the 
sequence field data in SEQ_1 is decremented by 2 from the previous valuers passed in with the 
input), and the sequence field data in SEQ_2 is decremented by 1 from the previous value (as 
passed in with the input). 

1 0 Additional InputParameterCheck value must be provided for the parameters not included in the 
S/G E , if the transmission between the System and Ink Refill OA Device is error prone, and these 
errors are not corrected by the transmission protocol itself. InputParameterCheck is SHA- 
1[FieldNumL \ FieldNumE \ XferValLength \ XferVal], and is required to ensure the integrity of these 
parameters, when these inputs are received by the Ink Refill OA Device. This will prevent an 

1 5 incorrect transfer amount being deducted. 

The XferAmount function must first calculate the SHA- 1[FieldNumL \ FieldNumE \ XferValLength \ 
XferVal], compare the calculated value to the value received (InputParameterCheck) and only if the 
values match act upon the inputs. 
27.1 .2 Input parameters 

20 Table 289 describes each of the input parameters for XferAmount function. 



Parameter 


Description 


KeyRef 


For comsmon key input and output signature: KeyRef.keyNum = Slot number of 
the key to be used for testing input signature and producing the output signature. 
S/G e produced using K Key Ref.keyNum by the OA Device being upgraded. SIGout 
produced using K Ke yRef.keyNum for delivery to the OA Device being upgraded. 
KeyRef.useChipId = 0 




For variant key input and output signatures: KeyRef.keyNum = Slot number of 
the key to be used for generating the variant key. S/G E produced using a variant 
of KKeyRef.keyNum by the OA Device being upgraded. SIGout produced using a 
Variant of K Ke yRef.keyNumfor delivery to the OA Device being upgraded. 
KeyRef.useChipId = 1 KeyRef. chipld = Chipld of the device which generated 
S/G E and will receive SIGout. 


M0 Of External 


All 1 6 words of M o of the OA Device being upgraded. 


uxOfExtemal 


All 16 words of M i of the OA Device being upgraded. 


Chipld 


Chipld of the OA Device being upgraded. 
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FieldNumL 


mo field number of the local (refill) device from which the value will be transferred. 


FieldNumE 


mo field number of the OA Device being upgraded to which the value will be 
transferred. 


XferValLength 


XferVal length in words. Non zero length required. j 


XferVal 


The logical amount that will be transferred from the local device to the external 
device. 


Re 


External random value used to verify input signature. This will be the R from the 
input signature generator (i.e device generating SIGe). The input signal generator 
in this case, is the device being upgraded or a translation device. 




External random value used to produce output signature. This will be R obtained 
by calling the Random function on the device which will receive the SIG out from 
the XferAmount function. The device receiving the 57G out in this case, is the 
device being upgraded or a translation device. 


S/G E 


External signature required for authenticating input data. The input data in this 
case, is the output from the Read function performed on the device being 
upgraded. 

A correct S/G E = SIG Key Ref{Data | Re | Rl). 



27. 1.2.1 Input signature verification data format 

The input signature passed in to the XferAmount function is the output signature from the Read 
function of the Ink QA Device. 

Figure 382 shows the input signature verification data format for the XferAmount function. 
Table 290 gives the parameters included in S/G E for XferAmount. 



Parameter 


Length in bits 


Value set internally 


Value set from Input 


RWSense 


3 


000 

Refer to Section 
15.3.1.1 




MSelect 


4 


0011 




KeyldSelect 


8 


00000000 




Chipld 


48 




Chipld of the QA 
Device being upgraded 


WordSelect for M 0 


16 


All bits set to 1 




WordSelect for M, 


16 


All bits set to 1 
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MO 


512 




O 


Ml 


512 




O 


Re 


160 




O 


Rl 


160 


Based on the internal R 


O 



The XferAmount function is not passed all the parameters required to generate S/G E . For producing 
S/G L which is used to test S/G E , the function uses the expected values of some the parameters. 
27.1 .3 Output parameters 
5 Table 291 describes each of the output parameters for XferAmount. 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did not 
complete successfully, the reason for the failure is returned here. See 
Table 47. 


FieldSelect 


Selection of fields to be written 

In this case the bit corresponding to SEQ_1 , SEQ_2 and to FieldNumE 
are set to 1 . 

All other bits are set to 0. 


FieldVal 


Updated data words for Sequence data field and FieldNumE for QA 
Device being upgraded. 
Starts with LSW of lower field. 

This must be passed as input to the WriteFieldsAuth function of the QA 
Device being upgraded. 


R\_2 


Internal random value required to generate output signature. This must be 
passed as input to the WriteFieldsAuth function or Translate function of 
the QA Device being upgraded. 


S/G out 


Output signature which must be passed as an input to the WriteFieldsAuth 

function of the QA Device being upgraded. 

SIGout = SIG Key Ref(data | Rl2 I Re2> as per Figure 373. 



10 
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Table 292. Result Flag definitions for XferAmount 



ResultFlag Definition 


Description 


FieldNumElnvalid 


FieldNum to which the amount is being transferred, or which is being 
upgraded in the OA Device being upgraded is invalid. 


Seq Field Invalid 


The sequence field for the OA Device being upgraded is invalid. 


FieldNumEWritePermlnvalid 


FieldNum to which the amount is being transferred, or which is being 
upgraded in the OA Device being upgraded has no authenticated write 
permission. 


FieldNumLlnvalid 


FieldNum from which the amount is being transferred, or from which 
the value is being copied in the Upgrading QA Device is invalid. 


FieldNumLWritePermlnvalid 


FieldNum from which the amount is being transferred in the Upgrading 
QA Device has no authenticated permission, or no authenticated 
permission with the KeyRef. 


TypeMismatch 


Type of the data from which the amount is being transferred in the 
Upgrading QA Device, doesn't match the Type of data to which the 
amount in being transferred in the Device being upgraded. 


UpgradeFieldElnvalid 


Only applicable for transferring count-remaining values. The upgrade 
field associated with the count-remaining field in the QA Device being 
upgraded is invalid. 


UpgradeFieldLlnvalid ! 


Only applicable for transferring count-remaining values. The upgrade 
field associated with the count-remaining field in the Upgrading QA 
Device is invalid. 


UpgradeFieldMismatch 


Only applicable for transferring count-remaining values. 

Type of the data in the upgrade field in the Upgrading QA Device, 

doesn't match the Type of data in the upgrade field in the Device being 

upgraded. 


FieldNum ESizelnsufficient 


FieldNum to which the amount is being transferred, or which is being 
upgraded in the QA Device is not big enough to store the transferred 
data. 


FieldNumLAmountlnsufficient 


FieldNum in the Upgrading QA Device from which the amount is being 
transferred doesn't have the amount required for the transfer. 



27.1.3.1 S/Gout 

Refer to Section 20.2.1 for details. 
27.1.4 Function sequence 

The XferAmount command is illustrated by the following pseudocode: 
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Accept input parameters - KeyRe f , MOOf External , MIOf External , 
Chipld, FieldNumL, FieldNumE, Xf erValLength 

# Accept XferVal words 
For i f-0 to Xf erValLength 

Accept next XferVal 
EndFor 

Accept R E , SIG E , R B2 

^Generate message for passing into ValidateKeyRefAndSignature 
function 

data <- (RWSense|MSelect|KeyIdSelect|ChipId|WordSelect|MO|Ml) 
# Refer to Figure 382. 



# Validate KeyRe f , and then verify signature 

ResultFlag = ValidateKeyRefAndSignature (KeyRe f, data, R E/ R L ) 

If (ResultFlag * Pass) 

Output ResultFlag 

Return 
Endlf 



^Validate FieldNumE 

# FieldNumE is present in the device being upgraded 
PresentFlagFieldNumE <- GetFieldPresent (MIOf External , FieldNumE) 

# Check FieldNumE present flag 
If (PresentFlagFieldNumE * 1) 

ResultFlag <- FieldNumE Invalid 
Output ResultFlag 
Return 
Endlf 
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# Check Seq Fields Exist and get their Field Num 

# Get Seqdata field SEQ_1 num for the device being upgraded 
XferSEQ_lFieldNum<- GetFieldNum (MIOf External , SEQ_1) 

# Check if the Seqdata field SEQ_1 is valid 
If (Xf erSEQ_lFieldNum invalid) 

ResultFlag <- Seq Field Invalid 
Output ResultFlag 
Return 
Endlf 

# Get Segdata field SEQ_2 num for the device being upgraded 
Xf erSEQ_2FieldNum<- GetFieldNum (MIOf External , SEQ_2 ) 

# Check if the Seqdata field SEQJZ is valid 
If (XferSEQ_2FieldNum invalid) 

ResultFlag <r~ SeqFieldlnvalid 
Output ResultFlag 
Return 
Endlf 



#Check write permission for FieldNumE 

PermOKFieldNumE <— Che ckFieldNumE Perm (MIOf External , FieldNumE) 
If (PermOKFieldNumE * 1) 

ResultFlag <r- FieldNumEWritePerm In valid 

Output ResultFlag 

Return 
Endlf 



#Check that both SeqData fields have Decrement -Only permission 
with the same key 

Uthat has write permission on FieldNumE 

PermOKXf erSeqData <- CheckSeqDataFieldPerms (MIOf External , 

XferSEQ_lFieldNum, 
XferSEQ_2FieldNum, FieldNumE) 
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If (PermOKXferSeqData * 1) 

ResultFlag <— SeqWritePerm Invalid 

Output ResultFlag 

Return 

Endlf 



# Get SeqData SEQ_1 data from device being upgraded 
GetFieldDataWords (Xf erSEQ_lFieldNum / 

Xf erSEQ_lDataFromDevice , MOOf External , MIOf External ) 

# Get SegData SEQ_2 data from device being upgraded 
GetFieldDataWords (Xf erSEQ_2FieldNum, 

Xf erSEQ_2DataFromDevice , 
MOOf External , MIOf External ) 



# FieldNumL is a present in the refill device 
PresentFlagFieldNumL <- GetFieldPresent (Ml , FieldNumL) 
If (PresentFlagFieldNumL * 1) 

ResultFlag <- FieldNumL Invalid 

Output ResultFlag 

Return 
Endlf 

#Check permission for FieldNumL 

PermOKFieldNumL <- Che ckFieldNumL Perm (Ml , FieldNumL, KeyRef ) 
If (PermOKFieldNumL * 1) 

ResultFlag «- FieldNumLWritePerm Invalid 

Output ResultFlag 

Return 
Endlf 



#Find the type attribute for FieldNumE 
TypeFieldNumE <- FindFieldNumType(M1 Of External, FieldNumE) 
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UFind the type attribute for FieldNumL 
TypeFieldNumL <— FindFieldNumType (Ml, FieldNumL) 

# Check type attribute for both fields match 
If(TypeFieldNumE ^TypeFieldNumL) 

ResultFlag <r- TypeMismatch 

Output ResultFlag 

Return 
Endlf 



Do this if the Refill Device is tranf erring Count -remaining for Printer 
upgrades 

# If the Type is count remaining, check that upgrade values 
associated with 

# the count remaining are valid. Refer to Section 28. for further 
details on 

# count remaining and upgrade value. 

If (TypeFieldNumL = TYPE_COUNT_REMAINING) A (TypeFieldNumE 
=TYPE_COUNT_REMAINING ) 

#Upgrade value field is lower adjoining field 

UpgradeValueFieldNumE = FieldNumE -1 

If (Upgrade ValueFieldNumE < 0) # upgrade field doesn't exist for 
QA Device being upgraded 

ResultFlag <r- UpgradeFieldElnvalid 
Output ResultFlag 
Return 
Endlf 

UpgradeValueFieldNumL - FieldNumL - 1 

If (Upgrade ValueFieldNumL < 0) # upgrade field doesn't exist for 
local device 

ResultFlag +- UpgradeFieldLlnvalid 

Output ResultFlag 

Return 
Endlf 
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UpgradeValueCheckOK <- 
UpgradeValCheck (UpgradeValueFieldNumL, MO , Ml , 

UpgradeValueFieldNumL, MOOf External , MIOf External , KeyRef ) 
5 If (UpgradeValueCheckOK = 0) 

ResultFlag <- UpgradeFieldMismatch 
Output ResultFlag 
Return 
Endlf 
10 Endlf 

# Do this if Field Type is Count Remaining end 



15 #Check whether the device being upgraded can hold the transfer 

amount 

#(XferVal + AmountLeft 

OverFlow <- CanHold ( FieldNumE , MOOf External , Xf erVal ) 
If OverFlow error 
20 ResultFlag <- FieldNumESizelnsufficient 

Output ResultFlag 

Return 
Endlf 



25 

#Check the refill device has the desired amount (XferVal < = 
AmountLeft; 

UnderFlow <- HasAmount (FieldNumL, MO , XferVal) 
If UnderFlow error 
30 ResultFlag <- Field NumLAmountlnsufficient 

Output ResultFlag 

Return 
Endlf 



35 # All checks complete 

# Generate Seqdata for SEQ_1 and SEQ_2 fields 
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Xf erSEQ_lDataToDevice = Xf erSEQ_lDataFromDevice - 2 
XferSEQ_2DataToDevice = Xf erSEQ_2DataFromDevice - 1 

# Add DataSet to Xfer Entry Cache 

AddDataSetToXf erEntryCache (Chipld, FieldNumE, FieldNumL, 
Xf erLength, XferVal, Xf erSEQ_lDataFromDevice, 
Xf erSEQ_2DataFromDevice) 

# Get cur-rent FieldDataE field data words to write to Xfer Entry 
cache 

GetFieldDataWords (FieldNumE, FieldDataE, MO Of External , MIOf External) 

#Deduct XferVal from FieldNumL and Write new value 
DeductAndWriteValToFieldNumL (XferVal , FieldNumL, MO ) 

^Generate new field data words for FieldNumE. The current 
FieldDataE is added to 

# XferVal to generate new FieldDataE 
GenerateNewFieldData (FieldNumE, XferVal, FieldDataE) 

# Generate FieldSelect and FieldVal for SeqData field SEQ_1, SEQJ2 
and 

# FieldDataE. . . 
CurrentFieldSelect<- 0 
FieldVal <- 0 

GenerateFieldSelectAndFieldVal (FieldNumE, FieldDataE, 
XferSEQ_lFieldNum, Xf erSEQ_lDataToDevice, Xf erSEQ_2FieldNum, 
Xf erSEQ_2DataToDevice , 
FieldSelect, FieldVal) 

^Generate message for passing into Generates ignature function 
data (RWSense | FieldSelect | Chipld | FieldVal) # Refer to Figure 373. 
#Create output signature for FieldNumE 
SIG out ^- Generates ignature (KeyRef , data, R^ , R E2 ) 
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Update Rls to Rl3 
ResultFlag <— Pass 

Output ResultFlag, FieldData, Rl2 ,SIG out 
Return 
5 Endlf 

27.1.4.1 ResultFlag ValidateKeyRefAndSfgnature(KeyRef f data f R E ,Ri) 

This function checks KeyRef is valid, and if KeyRef is valid, then input signature is verified using 
KeyRef. 

CheckRange (KeyRef . keyNum) 
10 If invalid 

ResultFlag <— InValidKey 

Output ResultFlag 

Return 
Endlf 

15 

^Generate message for passing into Generates ignature function 
data <r- (RWSense|MSelect | KeyldSelect | Chipld | WordSelect |M0 |M1) 
# Refer to Figure 382. 
20 #Generate Signature 

SIG L <— GenerateSignature (KeyRef , data, R E , R L ) 

# Check input signature SIGe 
If (SIG L = SIGe) 
25 Update R L to R L2 

Else 

ResultFlag <~ Bad Signature 
Output ResultFlag 
Return 
30 Endlf 

27.1.4.2 GenerateFieldSelectAndFieldVal (FieldNumE, FieldDataE, 
XferSEQ_1FieldNum, XferSEQ_1 DataToDevice, XferSEQ_2FieldNum, 
XferSEQ_2DataToDevice, FieldSelect, FieldVal) 

This functions generates the FieldSelect and FieldVal for output from FieldNumE and its final data, 
35 and data to be written to Seq fields SEQ_1 and SEQ_2. 

27.1.4.3 PresentFlag GetFieldPresent(M1,FieldNum) 
This function checks whether FieldNum is a valid. 
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FieldSize [16] <— 0 # Array to hold FieldSize assuming there are 16 
fields 



NumFields*- FindNumberOf Fields InMO (Ml , FieldSize) #Refer to Section 
5 19.4.1 

If(FieldNum< NumFields) 

PresentFlag<— 1 
Else 

PresentFlag<— 0 
10 Endlf 

Return PresentFlag 

27.1.4.4 NumFields FindNumOfFieldslnM0(M\,FieldSizeQ) 
Refer to Figure 19.4.1 for details. 

27.1.4.5 FieldNumGetFieldNum(M1,Type) 

1 5 This function returns the field number based on the Type. 

FieldSize [16] <- 0 # Array to hold FieldSize assuming there are 16 
fields 

NumFields*- FindNumberOf FieldsInMO (Ml t FieldSize) #Refer to Section 
19.4 .1 

20 For i = 0 to NumFields 

If(Ml[i] .Type = Type) 

Return i # This is field Num for matching field 
EndFor 

i = 255 # If XferSession field was not found then return an 
25 invalid value 

Return i 

27. 1.4.6 PermOK CheckFieldNumEPerm(M1,FieldNumE) 

This function checks authenticated write permission for FieldNum which holds the upgraded value. 

AuthRW <- Ml [FieldNum] . AuthRW 
30 NonAuthRW <r- Ml [FieldNum] .NonAuthRW 

If (AuthRW = 1) A (NonAuthRW = 0) 

PermOK <- 1 
Else 

PermOK <— 0 
35 Endlf 

Return PermOK 
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27. 1.4. 7 PermOK CheckSeqDataFieldPerms(M1 , XferSEQ_1FieIdNum, 
XferSEQ_2Fie!dNum, FieldNumE) 

This function checks that both SeqData fields have Decrement-Only permission with the same 
key that has write permission on FieldNumE. 
5 KeyNumForFieldNumE <- Ml [FieldNumE] . KeyNum # Isolate KeyNum for the 

field that will 

# be upgraded 

# Isolate KeyNum for both SeqData fields and check that they can 
be written using the same key 

10 KeyNumFo r S EQ_ 1 <- Ml [Xf erSEQ_lFieldNum] . KeyNum 

KeyNumForSEQ_2 <- Ml [Xf erSEQ_2FieldNum] .KeyNum 
I f ( KeyNumFor SEQ_1 * KeyNumFo rSEQ_2 ) 
PermOK <r- 0 
Return PermOK 
15 Endlf 

# Check that the write key for FieldNumE and SeqData field is not 
the same 

If ( KeyNumFo rSEQ_l = KeyNumForFieldNumE) 
PermOK <— 0 
20 Return PermOK 

Endlf 

#Isolate Decrement -Only permissions with the write key of 
FieldNumE 

KeyPermsSEQ_l «- Ml [Xf erSEQ_lFieldNum] . Key Perms [KeyNumForFieldNumE] 
25 KeyPermsSEQ_2 <- Ml [Xf erSEQ_2FieldNum] . Key Perms [KeyNumForFieldNumE] 

# Check that both sequence fields have Decrement -Only permission 
for this key 

If (KeyPermsSEQ_l =0) v (KeyPermsSEQ_2 = 0) 
PermOK <— 0 
30 Return PermOK 

Endlf 

PermOK <— 1 
Return PermOK 

27.1.4.8 AddDataSetToXferEntryCache (Chipld, FieldNumE, FieldNumL, 
35 XferVal, SEQ_1Data, SEQ_2Data) 
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This function adds a new dataset to the Xfer Entry cache. Dataset is a single record in the Xfer 
Entrycache. Refer to Section 27 for details. 

# Search for matching Chipld FieldNumE is Cache 

5 DataSet <-SearchDataSetInCache (Chipld, FieldNumE) 

# If found 

If (DataSet is valid) 

DeleteDataSetlnCache (DataSet) # This creates a vacant dataset 
AddRecordToCache (Chipld, FieldNumE , FieldDataL, XferVal , SEQ_lData, 
10 SEQ_2Data) 

Endlf 

# Searches the cache for XferState complete/deleted 
Founds- SearchRecordsInCache (complete/deleted) 

If (Found =1) 

15 AddRecordToCache (Chipld, FieldNumE, FieldDataL, XferVal , SEQ_lData, 

SEQ_2Data) 
Else 

# This will overwrite the oldest DataSet in cache 

AddRecordToCache (Chipld, FieldNumE, FieldDataL, XferVal , SEQ_lData, 
20 SEQ_2Data) 
Return 
Endif 

Set XferState in record to Xfer 
Return 

25 27.1.4.9 FieldTypeFindFieldNumType(M1,FieldNum) 

This function gets the Type attribute for a given field. 
FieldType <- Ml [FieldNum] .Type 
Return FieldType 
27. 1.4. 10 PermOK CheckFie/dNumLPerm(M1,FieldNumL,KeyRef) 
30 This function checks authenticated write permissions using KeyRef for FieldNumL in the refill 
device. 

AuthRW <- M1 [FieldNumL] .AuthRW 
KeyNumAtt <- M 1 [FieldNumL] . KeyNum 
DOForKeys <- M 1 [FieldNumL] .DOForKeys [KeyNum] 
35 # Authenticated write allowed 

# ReadWrite key for field is the same as Input KeyRef . keyNum 

# Key has both ReadWrite and DecrementOnly Permission 
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If (AuthRW =1) a (KeyRef . keyNum = KeyNumAtt) a (DOForKeys = 1 

PermOK<— 1 
Else 

PermOK<— 0 
Endlf 

Return PermOK 

27.1.4.11 CheckOK UpgradeValCheck(FieldNum1, MOOfFieldNuml, MIOfFiefdNuml, 

FieldNum2, M0OfFieldNum2, M10fFieldNum2,KeyRef) 
This function checks the upgrade value corresponding to the count remaining. The upgrade value 
corresponding to the count remaining field is stored in the lower adjoining field. To upgrade the 
count remaining field, the upgrade value in refill device and the device being upgraded must match. 

#Check authenticated write permissions is allowed to the field 

#Check that only one key has ReadWrite access, 

#and all other keys are Readonly access 

PermCheckOKFieldNuml 

<-CheckUpgradeKeyForField (FieldNuml , MIOf FieldNuml , KeyRef) 
If (PermCheckOKFieldNuml * 1) 

CheckOK <- 0 

Return CheckOK 
Endlf 

Pe rmChe ckOKF i e 1 dNum2 

^CheckUpgradeKeyForField (FieldNum2 , MIOf FieldNum2 , KeyRef) 
If (PermCheckOKFieldNum2 * 1) 

CheckOK <- 0 

Return CheckOK 
Endlf 

#Get the upgrade value associated with field 

GetFieldDataWords ( FieldNuml , Upgrade ValueFieldNuml , MOOfFieldNuml , Ml 
OfFieldNuml) 

#Get the upgrade value associated with field 

GetFieldDataWords ( FieldNum2 , UpgradeValueFieldNum2 , MOOf FieldNum2 , Ml 
OfFieldNum2) 
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If (UpgradeValueFieldNuml * UpgradeValueFieldNum2 ) 

CheckOK <- 0 

Return CheckOK 
Endlf 

5 # Get the type attribute for the field 

UpgradeTypeFieldNuml^- GetUpgradeType (FieldNuml , MIOf FieldNuml) 
UpgradeTypeFieldNum2<- GetUpgradeType (Fie ldNum2 , MIOf FieldNum2 ) 
If (UpgradeTypeFieldNuml * UpgradeTypeFieldNum2 ) 
CheckOK <- 0 
10 Return CheckOK 

Endlf 

CheckOK 1 

Return CheckOK 
27. 1.4. 12 CheckOK CheckUpgradeKeyForField(FieldNum,M1,KeyRef) 
1 5 This function checks that authenticated write permissions is allowed to the field. It also checks that 
only one key has ReadWrite access and all other keys have Readonly access. KeyRef which 
updates count remaining must not have write access to the upgarde value field. 

KeyNum <-Ml [FieldNum] .KeyNum 

AuthRW <- Ml [FieldNum] .AuthRW 
20 NonAuthRW <- Ml [FieldNum] .NonAuthRW 

DOForKeys<— Ml [FieldNum] .DOForKeys 

UCheck that KeyRef doesn't have write permissions to the field 
If (KeyRef .keyNum = KeyNum) 
CheckOK <-0 
25 Return CheckOK 

Endlf 

#AuthRW access allowed or NonAuthRW not allowed 
If (AuthRW = 0) v (NonAuthRW =1) 
CheckOK <-0 
30 Return CheckOK 

Endlf 

For i <— 0 to 7 

# Keys other than KeyNum are allowed Readonly access, 

# DecrementOnly access not allowed for other keys (not KeyNum) 
35 If (i * KeyNum) a (DOForKeys [ij = 1) 

CheckOK <-0 
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Return CheckOK 
Endlf 

#ReadWrite access allowed for KeyNum, 

#ReadWrite and DecrementOnly access not allowed for KeyNum. 
5 If (i = KeyNum) a (DOForKeys [i] = 1) 

CheckOK <-0 
Return CheckOK 
Endlf 
EndFor 
1 0 CheckOK <- 1 

Return CheckOK 
27.1 .4.1 3 UpgradeType GetUpgradeType(FieldNum, M1) 

This function gets the type attribute for the upgrade field. 
UpgradeType GetUpgradeType (FieldNum) 
15 UpgradeType*— Ml [FieldNum] .Type 

Return UpgradeType 
27. 1.4. 14 GetFieldDataWords(FieldNum,FieldDataQ, M0,M1) 
This function gets the words corresponding to a given field. 
CurrPos <— MaxWordlnM 
20 If FieldNum = 0 

CurrPos <— MaxWordlnM 
Else 

CurrPos <— (Ml [FieldNum -1] .EndPos) -1 # Next lower word after 
last word of the 

25 # previous 

field 
Endlf 

EndPos <- (Ml [FieldNum] . EndPos) 
For i <— EndPos to CurrPos j <— 0 
30 FieldData [j] <-M0[i] #Copy MO word to FieldData array 

EndFor 
27.2 StartRollBack 

Input: KeyRef, M0 OfExtemal, m OfExternaf, Chipld, FieldNumL, 

FieldNumE, InputParameterCheck (optional), R E , S/G E , R B2 
35 Output: ResultFlag t FieldSelect t FieldVal, R^ S/G^ 

Changes: M0 and R L 
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Availability Ink refill QA Device and Parameter Upgrader QA Device 

27. 2 .1 Function description 

StartRollBack function is used to start a rollback sequence if the QA Device being upgraded didn't 
receive the transfer message correctly and hence didn't receive the transfer. 
5 The system calls the function on the upgrading QA Device, passing in FieldNumE and Chipld of the 
QA Device being upgraded, and FieldNumL of the upgrading QA Device. The upgrading QA Device 
checks that the QA Device being upgraded didn't actually receive the message correctly, by 
comparing the values read from the device with the values stored in the Xfer Entry cache. The 
values compared is the value of the sequence fields. After all checks are fulfilled, the upgrading QA 

1 0 Device produces the new data for the sequence fields and a signature. This is subsequently applied 
to the QA Device being upgraded (using the WriteFieldAuth function), which updates the sequence 
fields SEQ_1 and SEQ_2 to the pre-rollback values. However, the new data for the sequence fields 
and signature can only be applied if the previous data for the sequence fields produced by Xfer 
function has not been written. 

1 5 The output from the StartRollBack function consists only of the field data of the two sequence fields, 
and a signature using the refill key. When a pre-rollback output is produced, then sequence field 
data in SEQ_f (as stored in the Xfer Entry cache, which is what is passed in to the Xfer Amount 
function) is decremented by 1 and the sequence field data in S£Q_2 (as stored in the Xfer Entry 
cache, which is what is passed in to the XferAmount function) is decremented by 2. 

20 Additional InputParameterCheck value must be provided for the parameters not included in the 
S/G E , if the transmission between the System and Ink Refill QA Device is error prone, and these 
errors are not corrected by the transimission protocol itself. InputParameterCheck is SHA- 
1 [FieldNumL \ FieldNumE ] t and is required to ensure the integrity of these parameters, when these 
inputs are received by the Ink Refill QA Device. 

25 The StartRollBack function must first calculate the SHA-1 [FieldNumL \ FieldNumE], compare the 

calculated value to the value received (InputParameterCheck) and only if the values match act upon 
the inputs. 

27.2.2 Input parameters 

30 Table 293 describes each of the input parameters for StartRollback function. 



Parameter 


Description 


KeyRef 


For common key input signature: KeyRef.keyNum = Slot number of the key to be 
used for testing input signature. S/G E produced using K Ke yR e f.keyNum by the QA 
Device being upgraded. KeyRef. useChipId = 0 




For variant key input signature: KeyRef.keyNum = Slot number of the key to be 
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used for generating the variant key for testing input signature. S/Ge produced 
using a variant of K K ©yR e fkeyNum by the OA Device being upgraded. 
KeyRef.useChipfd = 1 KeyRef.chipfd = Chipld of the device which generated 
S/G E . 


MoOfExternal 


All 16 words of M0 of the QA Device being upgraded which failed to upgrade. 


m Of External 


All 16 words of M i of the QA Device being upgraded which failed to upgrade. 


Chipld 


Chipld of the QA Device being upgraded which failed to upgrade. 


FieldNumL 


mo field number of the local (refill) device from which the value was supposed to 
transferred. 


FieldNumE 


mo field number of the QA Device being upgraded to which the value couldn't be 
transferred. 


Re 


External random value used to verify input signature. This will be the R from the 
input signature generator (i.e device generating S/GeJ. The input signal generator 
in this case, is the device which failed to upgrade or a translation device. 


S/G e 


External signature required for authenticating input data. The input data in this 
case, is the output from the Read function performed on the device which failed 
to upgrade. A correct S/G E = SIG Key Ref{Data | R E | R L ). 



27.2.2. 1 Input signature verification data format 

Refer to Section 27.1 .2.1 . 
27.2.3 Output parameters 

Table 294 describes each of the output parameters for StartRollback function. 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned here. 
See Section 12.1, Table 292 and Table 295. 


FieldSelect 


Selection of fields to be written 

In this case the bits corresponding to SEQ_1 and SEQ_2 are set to 1 . 
All other bits are set to 0. 


FieldVal 


Updated data for sequence datat field for QA Device being upgraded. 
This must be passed as input to the WriteFieldsAuth function of the QA 
Device being upgraded. 


R\j2 


Internal random value required to generate output signature. This must 
be passed as input to the WriteFieldsAuth function or Translate 
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function of the QA Device being upgraded. 


S/G out 


Output signature which must be passed as an input to the 
WriteFieldsAuth function of the QA Device being upgraded. 
SIGout = SIG Key Ref(data | Rl2 1 R E 2> as per Figure 373. 



Table 295. Result definition for StartRollBack 



ResultFlag Definition 


Description 


RollBacklnvalid 


RollBack cannot be performed on the request because parameters for 
rollback is incorrect. 



27.2.3.1 S/Gout 

Refer to Section 20.2.1 for details. 
27.2.4 Function sequence 

The StartRollBack command is illustrated by the following pseudocode: 
1 0 Accept input parameters-KeyRef, MOOfExternal, MIOfExternal, Chipld, FieldNumL, 

FieldNumE, Re, SIG e> Re 2 

Accept R E/ SIG E/ R E2 

^Generate message for passing into ValidateKeyRefAndSignature 
1 5 function 

data <- (RWSense|MSelect | KeyldSelect | Chipld | WordSelect | MO | Ml) 
# Refer to Figure 382. 



20 # Validate KeyRef, and then verify signature 

ResultFlag = ValidateKeyRefAndSignature (KeyRef , data, R E , R L ) 
If (ResultFlag * Pass) 
Output ResultFlag 
Return 
25 Endlf 

# 

Check Seq Fields Exist and get their Field Num 

# Get Seqdata field SEQ_1 num for the device being upgraded 

Xf erSEQ_lFieldNum<- GetFieldNum (MIOf External , SEQ_1) 

30 
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# Check if the Seqdata field SEQ_1 is valid 
If (XferSEQ_lFieldNum invalid) 

ResultFlag <- Seq Field Invalid 
Output ResultFlag 
Return 
Endlf 

# Get Segdata field SEQJ2 num for the device being upgraded 
Xf erSEQ_2FieldNum<- GetFieldNum (MlOf External , SEQ_2 ) 

# Check if the Seqdata field SEQJ2 is valid 
If (XferSEQ_2FieldNum invalid) 

ResultFlag <- Seq Field Invalid 
Output ResultFlag 
Return 
Endlf 



# Get SeqData SEQ_1 data from device being upgraded 
GetFieldDataWords (Xf erSEQ_lFieldNum, 

Xf erSEQ_lDataFromDevice , MOOf External , MlOf External ) 

# Get SeqData SEQ__2 data from device being upgraded 
GetFieldDataWords (Xf erSEQ_2FieldNum, 

Xf erSEQ_2DataFromDevice , 
MOOf External , MlOf External ) 



# Check Xfer Entry in cache is correct - dataset exists, Field 
data 

# and sequence field data matches and Xfer State is correct 
XferEntryOK <- CheckEntry (Chipld, FieldNumE, FieldNumL, 

Xf erSEQ_lDataFromDevice, Xf erSEQ_2DataFromDevice) 

If( XferEntryOK= 0) 

ResultFlag <- RollBacklnvalid 
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Output ResultFlag 
Return 
Endlf 

# Generate Seqdata for SEQ_1 and SEQ_2 fields 
XferSEQ_lDataToDevice = Xf erSEQ_lDataFromDevice - 1 
Xf erSEQ_2DataToDevice = Xf erSEQ_2DataFromDevice - 2 



10 # Generate FleldSelect and FieldVal for sequence fields SEQ_1 and 

SEQ_2 

CurrentFieldSelect<— 0 
FieldVal <- 0 

GenerateFieldSelectAndFieldVal (Xf erSEQ_lFieldNum, 
1 5 Xf erSEQ_lDataToDevice, Xf erSEQ_2FieldNum, Xf erSEQ_2DataToDevice, 

FieldSelect , FieldVal ) 



#Generate message for passing into Generates ignature function 
data <- (RWSense | FieldSelect | Chipld | FieldVal) # Refer to Figure 373. 
20 #Creafce output signature for FieldNumE 

SIG out ^- GenerateSignature (KeyRef , data, R L2 , R E 2> 
Update R L2 to R L3 
ResultFlag <— Pass 

Output ResultFlag, FieldData, R L2 ,SIG out 
25 Return 
Endlf 

27.3 RollBackAmount 

Input: KeyRef, m OfExternal, m OfExtemal, Chipld, FieldNumL, 

FieldNumE, InputParameterCheck (optional), R E , S/G E 
30 Output: ResultFlag 

Changes: M0 and R L 

Availablity: Ink refill QA Device 

27.3.1 Function description 

RollBackAmount function finally adjusts the value of the FieldNumL of the upgarding QA Device to a 
35 previous value before the transfer request, if the QA Device being upgraded didn't receive the 
transfer message correctly (and hence was not upgraded). 
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The upgrading OA Device checks that the QA Device being upgraded didn't actually receive the 
transfer message correctly, by comparing the sequence data field values read from the device with 
the values stored in the Xfer Entry cache. The sequence data field values read must match what 
was previously written using the StartRoIlBack function. After all checks are fulfilled, the upgrading 
5 QA Device adjusts its FieldNumL. 

Additional InputParameterCheck value must be provided for the parameters not included in the 
S/G E , if the transmission between the System and Ink Refill QA Device is error prone, and these 
errors are not corrected by the transmission protocol itself. InputParameterCheck is SHA- 
1 [FieldNumL \ FieldNumE ], and is required to ensure the integrity of these parameters, when these 
1 0 inputs are received by the Ink Refill QA Device. 

The RollBackAmount function must first calculate the SHA-1 [FieldNumL \ FieldNumE], compare the 
calculated value to the value received (InputParameterCheck) and only if the values match act upon 
the inputs. 

27.3.2 Input parameters 
1 5 Table 296 describes each of the input parameters for RollbackAmount function. 



Parameter 


Description 


KeyRef 


For common key input signature: KeyRef.keyNum = Slot number of the key to be 
used for testing input signature. S/G E produced using K Ke yRef.keyNum by the QA 
Device being upgraded. KeyRef. useChipId = 0 




For variant key input signature: KeyRef.keyNum = Slot number of the key to be 
used for generating the variant key for testing input signature. S/G E produced 
using a variant of KKeyRef.keyNum by the QA Device being upgraded. 
KeyRef.useChipId = 1 KeyRef.chipId = Chipld of the device which generated 
S/G E . 


MoOfExternal 


All 1 6 words of M0 of the QA Device being upgraded which failed to upgrade. 


m Of External 


All 16 words of M i of the QA Device being upgraded which failed to upgrade. 


Chipld 


Chipld of the QA Device being upgraded which failed to upgrade. 


FieldNumL 


mo field number of the local (refill) device from which the value was supposed to 
transferred. 


FieldNumE 


mo field number of the QA Device being upgraded to which the value was not 
transferred. 


Re 


External random value used to verify input signature. This will be the R from the 
input signature generator (i.e device generating SIGe). The input signal generator 
in this case, is the device which failed to upgrade or a translation device. 


S/G E 


External signature required for authenticating input data. The input data in this 
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case, is the output from the Read function performed on the device which failed 
to upgrade. A correct S/G E = SIG Ke yRef(Data | Re | RJ. 



27.3.2. 1 Input signature generation data format 

Refer to Section 27.1 .2.1 for details. 
27.3.3 Output parameters 

Table 297 describes each of the output parameters for RollbackAmount. 



Parameter 


Description 


ResultFlag 

i 


Indicates whether the function completed successfully or not. If it 
did not complete successfully, the reason for the failure is 
returned here. See Section 12.1, Table 292 and Table 295. 



27.3.4 Function sequence 

The RollBackAmount command is illustrated by the following pseudocode: 
Accept input parameters -KeyRef , MOOf External , MIOf External , 
Chipld, FieldNumL, FieldNumE, R e ,SIGe 

#Generate message for passing into ValidateKeyRefAndSignature 
function 

data <- (RWSense|MSelect | KeyldSelect | Chipld | WordSelect |M0 |M1) 
# Refer to Figure 382. 



# Validate KeyRef, and then verify signature 

ResultFlag = ValidateKeyRefAndSignature (KeyRef , data, R E/ R L ) 

If (ResultFlag * Pass) 

Output ResultFlag 

Return 
Endlf 



# Check Seq Fields Exist and get their Field Num 

# Get Seqdata field SEQ_1 num for the device being upgraded 
XferSEQ_lFieldNum<- GetFieldNum(M10f External, SEQ_1) 

# Ciiecx if the Seqdata. field SEQ_1 is valid 
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If (XferSEQ_lFieldNum invalid) 

ResultFlag <- Seq Field Invalid 

Output ResultFlag 

Return 
Endlf 

# Get Seqdata field SEQ_2 num for the device being upgraded 
Xf erSEQ_2FieldNum<- GetFieldNum (MIOf External , SEQ_2 ) 

# Check if the Seqdata field SEQ_2 is valid 
If (XferSEQ_2FieldNum invalid) 

ResultFlag <- Seq Field Invalid 
Output ResultFlag 
Return 
Endlf 



# Get SegData SEQ_1 data from device being upgraded 
GetFieldDataWords (Xf erSEQ_lFieldNum, 

Xf erSEQ_lDataFromDevice , MOOf External , MIOf External ) 

# Get SeqData SEQ_2 data from device being upgraded 
GetFieldDataWords (Xf erSEQ_2FieldNum, 

Xf erSEQ_2DataFromDevice, 
MOOf External , MIOf External) 



# Generate Seqdata for SEQ_1 and SEQJ2 fields with the data that 
is read 

Xf erSEQ_lData = Xf erSEQ_lDataFromDevice + 1 
Xf erSEQ_2Data = Xf erSEQ_2DataFromDevice + 2 

# Check Xfer Entry in cache is correct - dataset exists, Field 
data 

# and sequence field data matches and Xfer State is correct 
XferEntryOK <- CheckEntry (Chipld, FieldNumE, FieldNumL, 

XferSEQ_lData, Xf erSEQ_2Data) 
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If( XferEntryOK= 0) 

ResultFlag <— RollBacklnvalid 

Output ResultFlag 

Return 
Endlf 

# Get AFieldDataL from DataSet 
GetVal (Chipld, FieldNumE, AFieldDataL) 

# Add AFieldDataL to FieldNumL 
AddValToField (FieldNumL, AFieldDataL) 

# Update XferState in DataSet to complete/deleted 
UpdateXf erStateToComplete (Chipld, FieldNumE) 
ResultFlag <— Pass 

Output ResultFlag 
Return 
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Functions 
Upgrade device 
(Printer upgrade) 
28 Concepts 

5 This section is very similar to Section 26. The differences between this section and Section 26 have 
been summarised and underlined, where required. 
28.1 Purpose 

In a printing application, a printer contains a Printer QA Device, which stores details of the various 
operating parameters of a printer, some of which may be upgradeable. The upgradeable 

1 0 parameters must be written (initially) and changed in an authorised manner. 

The authorisation for the write or change is achieved by using a Parameter Upgrader QA Device 
which contains the necessary functions to allow a write or a change of a parameter value (e.g. a 
print speed) into another QA Device, typically a printer QA Device. This QA Device is also referred 
to as an upgrading QA Device. 

15 A parameter upgrader QA Device is able to perform a fixed number of upgrades, and this number is 
effectively a consumable value. The number of upgrades remaining is also referred to as count- 
remaining. With each write/change of an operating parameter in a Printer QA Device, the count- 
remaining decreases by 1, and can be replenished by a value upgrader QA Device. 
The Parameter Upgrader QA Device can also be referred to as the Upgrading QA Device, and the 

20 Printer QA Device can also be referred to as the QA Device being upgraded. 

The writing or changing of the parameter can also be referred to as a transfer of a parameter. 
The Parameter Upgrader QA Device copies its parameter value field to the parameter value field of 
Printer QA Device, and decrements the count-remaining field associated with the parameter value 
field bv1. 

25 28.2 Requirements 

The transfer of a parameter has two basic requirements: 

o The transfer can only be performed if the transfer request is valid. The validity of the transfer 
request must be completely checked by the Parameter Upgrader QA Device, before it 
produces the required output for the transfer. It must not be possible to apply the transfer 
30 output to the Printer QA Device, if the Parameter Upgrader QA Device has been already 

been rolled back for that particular transfer, 
o A process of rollback is available if the transfer was not received by the Printer QA Device. 
A rollback is performed only if the rollback request is valid. The validity of the rollback 
request must be completely checked by the Parameter Upgrader QA Device , before the 
35 count-remaining value is incremented by 1 . It must not be possible to rollback an Parameter 

Upgrader QA Device for a transfer, which has already been applied to the Printer QA 
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Device i.e the Parameter Upgrader OA Device must only be rolled back for transfers that 
have actually failed. 



28.3 Basic scheme 
5 The transfer and rollback process is shown in Figure 383. 

Following is a sequential description of the transfer and rollback process: 

1 . The System Reads the memory vectors MO and M1 of the Printer QA Device. The output 
from the read which includes the MO and M1 words of the Printer QA Device, and a 
signature, is passed as an input to the Transfer Request. It is essential that MO and M1are 

1 0 read together. This ensures that the field information for MO fields are correct, and have not 

been modified, or substituted from another device. Entire MO and M1 must be read to verify 
the correctness of the subsequent Transfer Request by the Parameter Upgrader QA Device. 

2. The System makes a Transfer Request to the Parameter Upgrader QA Device with the field 
in the Parameter Upgrader QA Device whose data will be copied to the Printer QA Device, 

1 5 and the field in Printer QA Device to which this data will be copied to. The Transfer Request 

also includes the output from Read of the Printer QA Device. The Parameter Upgrader QA 
Device validates the Transfer Request based on the Read output, checks that it has enough 
count-remaining for a successful transfer, and then produces the necessary Transfer output 
The Transfer Output typically consists of new field data for the field being refilled or 

20 upgraded, additional field data required to ensure the correctness of transfer/rollback, along 

with a signature. 

3. The System then applies the Transfer Output on the Printer QA Device, by calling an 
authenticated Write on it, passing in the Transfer Output. The Write is either successful or 
not. If the Write is not successful, then the System will repeat calling the Write function using 

25 the same transfer output, which may be successful or not. If unsuccessful the System will 

initiate a rollback of the transfer. The rollback must be performed on the Parameter Upgrader 
QA Device, so that it can adjust its value to a previous value before the current Transfer 
Request was initiated. 

4. The System starts a rollback by Reading the memory vectors MO and M1 of the Printer QA 
30 Device. 

5. The System makes a StartRollBack Request to the Parameter Upgrader QA Device with 
same input parameters as the Transfer Request, and the output from Read in (4). The 
Parameter Upgrader QA Device validates the StartRollBack Request based on the Read 
output, and then produces the necessary Pre-rollback output. The Pre-rollback output 

35 typically consists only of additional field data along with a signature. 

6. The System then applies the Pre-rollback output on the Parameter Upgrader QA Device, by 
calling an authenticated Write on it, passing in the Pre-rollback output. The Write is either 
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successful or not. If the Write is not successful, then either (6), or (5) and (6) must be 
repeated. 

7. The System then Reads the memory vectors MO and M1 of the Printer OA Device. 

8. The System makes a RollBack Request to the Parameter Upgrader QA Device with same 
5 input parameters as the Transfer Request, and the output from Read (7). The Parameter 

Upgrader QA Device validates the RollBack Request based on the Read output, and then 
rolls back its count-remaining field by incrementing it by 1 . 
28.3.1 Transfer 

The Printer QA Device stores upgradeable operating parameter values in MO fields, and its 
1 0 corresponding M<\ words contains field information for its operating parameter fields. The field 
information consists of the size of the field, the Type of data stored in field and the access 
permission to the field. See Section 8.1 .1 for details. 

The Parameter Upgrader QA Device also stores the new operating parameter values (which will be 
written to the Printer QA Device) in its MO fields, and its coressponding hA^ words contains field 
1 5 information for the new operating parameter fields. Additionally, the Parameter Upgrader QA Device 
has a count-remaining field associated with the new operating parameter value field. The count- 
remaining field occupies the higher field position when compared to its associated operating 
parameter value field. 
28.3.1.1 Authorisation 

20 The basic authorisation for a transfer comes from a key, which has authenticated ReadWrite 

permission (stored in field information as KeyNum) to the operating parameter field in the Printer 
QA Device. We will refer to this key as the upgrade key. The same upgrade key must also have 
authenticated decrement-only permission to the count-remaining field (which decrements by 1 with 
every transfer) in the Parameter Upgrader QA Device. 

25 After validating the input upgrade request, the Parameter Upgrader QA Device will decrement the 
value of the count-remaining field by 1 , and produce data (by copying the data stored from its 
operating parameter field) and signature for the new operating parameter using the upgrade key. 
Note that the Parameter Upgrader QA Device can decrement its count-remaining field only if the 
upgrade key has the permission to decrement it. 

30 The data and signature produced by the Parameter Upgrader QA Device is subsequently applied to 
the Printer QA Device. The Printer QA Device will accept the new transferred operating parameter, 
only if the signature is valid. Note that the signature will only be valid if it was produced using the 
upgrade key which has write permission to the operating parameter field being written. 
The upgrade key has authenticated ReadWrite permission to the operating parameter field (which 

35 will change) in the Printer QA Device. The upgrade key has decrement-only permission to the the 
count-remaining field (which decrements bv 1 with every transfer of field) in the Parameter 
Upgrader QA Device. 
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28.3.1.2 Data Type matching 

The Parameter Upgrader QA Device validates the transfer request by matching the Type of the data 
in the field information of operating parameter field (stored in M1 ) of Printer QA Device to the Type 
of data in the field information of operating parameter field of the Parameter Upgrader QA Device. 
5 This ensures that equivalent data types are being transferred i.e Network_OEM1 _printspeed_1500 
is not transferred to Network_OEM1_printspeed_2000. 

28.3.1.3 Addition validation 

Additional validation of the transfer request must be performed before a transfer output is generated 
by the Parameter Upgrader QA Device. These are as follows: 
10 © For the Printer QA Device 

1 . Whether the field being upgraded is actually present. 

2. Whether the field being upgraded can hold the changed value. 
© For the Parameter Upgrader QA Device: 

1 . Whether the new operating parameter field and its associated count-remaining is actually 
1 5 present. 

2. Whether the count-remaining field has an upgrade left for the transfer to succeed. 

28. 3.1.4 Rollback facilitation 

To facilitate a rollback, the Parameter Upgrade QA Device will store a list of transfer requests 
processed by it. This list is referred to as the Xfer Entry cache. Each record in the list consists of the 
20 transfer parameters corresponding to the transfer request. 
28.3.2 Rollback 

A rollback request will be validated by looking through the Xfer Entry cache of the Parameter 
Upgrader QA Device. After the right transfer request is found the Parameter Upgrade QA Device 
checks that the output from the transfer request was not applied to the Printer QA Device by 

25 comparing the current Read of the Printer QA Device to the values in the Xfer Entry cache, and 

finally rolling back the Parameter Upgrader QA Device count-remaining field by incrementing it by 1 . 
The Parameter Upgrader QA Device must be absolutely sure that the Printer QA Device didn't 
receive the transfer. This factor determines the additional fields that must be written along with new 
operating parameter data, and also the parameters of the transfer request that must be stored in the 

30 Xfer Entry cache to facilitate a rollback, to prove that the Printer QA Device didn't actually receive 
the transfer. 

The rollback process increments the count-remaining field by 1 in the Parameter Upgrader QA 
Device. 

28.3.2.1 Sequence fields 
35 The rollback process must ensure that the transfer output (which was previously produced) for 
which the rollback is being performed, cannot be applied after the rollback has been performed. 
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How do we achieve this? There are two separate decrement-only sequence fields (SEQ_1 and 
SEQ_2) in the Printer OA Device which can only be decremented by the Parameter Upgrader QA 
Device using the upgrade key. The nature of data to be written to the sequence fields is such that 
either the transfer output or the pre-rollback output can be applied to the Printer QA Device, but not 
5 both i.e they must be mutually exclusive. Refer to Table 285 for details. 

The two sequence fields are initialised to OxFFFFFFFF using sequence key.The sequence key is 
different to the upgrade key, and has authenticated ReadWrite permission to both the sequence 
fields. 

The transfer output consists of the new data for the field being upgraded, field data of the two 
1 0 sequence fields, and a signature using the upgrade key. The field data for SEQ_1 is decremented 
by 2 from the original value that was passed in with the transfer request. The field data for SEQ_2 is 
decremented by 1 from the original value that was passed in with the transfer request. 
The pre-rollback output consists only of the field data for the two sequence fields, and a signature 
using the upgrade key. The field data for SEQ_1 is decremented by 1 from the original value that 
1 5 was passed in with the transfer request. The field data for SEQ_2 is decremented by 2 from the 
original value that was passed in with the transfer request. 

Since the two sequence fields are decrement-only fields, the writing of the transfer output to QA 
Device being upgraded will prevent the writing of the pre-rollback output to QA Device being 
upgraded, since the sequence fields are decrement-only fields, and only one possible set can be 

20 written. If the writing of the transfer output fails, then pre-rollback can be written. However, the 
transfer output cannot be written after the pre-rollback output has been written. 
Before a rollback is performed, the Parameter Upgrader QA Device must confirm that the sequence 
fields was successfully written to the pre-rollback values in the Printer QA Device. Because the 
sequence fields are decrement-only fields, the Printer QA Device will allow pre-rollback output to be 

25 written only if the transfer output has not been written. 

28.3.2.1 .1 Field information of the sequence data field 

For a device to be upgradeable the device must have two sequence fields SEQ_1 and SEQ_2 
which are written with sequence data during the transfer sequence. Thus all upgrading QA Devices, 
ink QA Devices and printer QA Devices must have two sequence fields. The upgrading QA Devices 
30 must have these fields because they can be upgraded as well. The sequence field information are 
defined in Table 298. 
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Attribute Name 


Value 


Explanation 


Type 


TYPE_SEQ_1 or TYPE_SEQ_2. 


See Appendix A for exact data. 


KeyNum 


Slot number of the sequence key. 


Only the sequence key has 
authenticated 

ReadWrite access to this field. 


Non Auth RW 
Perm b 


0 


Non authenticated ReadWrite 
is not allowed to the field. 


Auth RW Perm 0 


1 


Authenticated (key based) ReadWrite 
access 

is allowed to the field. 


KeyPerm 


KeyPermsfKeyNum] = 0 


KeyNum is the slot number of the 
sequence key, 

which has ReadWrite permission to the 
field. 




KeyPerms[Slot number of upgrade key] = 
1 


Upgrade key can decrement the 
sequence field. 


KeyPerms[others= 0 ..7(except upgrade 
key)] = 0 


All other keys have Readonly access. 


End Pos 




Set as required. Size is typically 1 word. 



a. This is a sample type only and is not included in the Type Map in Appendix A. 
5 b. Non authenticated Read Write permission, 
c. Authenticated Read Write permission. 
28.3.3 Upgrade states 

There are three states in an transfer sequence, the first state is initiated for every transfer, while the 
next two states are initiated only when the transfer fails. The states are - Xfer, StartRollback, and 
10 Rollback. 

28.3.3.1 Upgrade How 

Figure 384 shows a typical upgrade flow. 

28.3.3.2 Xfer 

This state indicates the start of the transfer process, and is the only state required if the transfer is 
1 5 successful. During this state, the Parameter Upgrader OA Device adds a new record to its Xfer 
Entry cache, decrements its count-remaining by 1, produces new operating parameter field, new 
sequence data (as described in Section 28.3.2.1) and a signature based on the upgrade key. 
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The Printer QA Device will subsequently write the new operating parameter field and new sequence 
data, after verifying the signature. If the new operating parameter field can be successfully written to 
the Printer QA Device, then this will finish a successful transfer. 

If the writing of the new amount is unsuccessful (result returned is BAD SIG ), the System will re- 
5 transmit the transfer output to the Printer QA Device, by calling the authenticated Write function on 
it again, using the same transfer output. 

If retrying to write the same transfer output fails repeatedly, the System will start the rollback 
process on Parameter Upgrader QA Device, by calling the Read function on the Printer QA Device, 
and subsequently calling the StartRollBack function on the Parameter Upgrader QA Device. After a 
1 0 successful rollback is performed, the System will invoke the transfer sequence again. 
28.3.3.3 StartRollBack 

This state indicates the start of the rollback process. During this state, the Parameter Upgrade QA 
Device produces the next sequence data and a signature based on the upgrade key. This is also 
called a pre-rollback, as described in Section 26.3.2. 
1 5 The pre-rollback output can only be written to the Printer QA Device, if the previous transfer output 
has not been written. The writing of the pre-rollback sequence data also ensures, that if the 
previous transfer output was captured and not applied, then it cannot be applied to the Printer QA 
Device in the future. 

If the writing of the pre-rollback output is unsuccessful (result returned is BAD SIG ), the System will 
. 20 re-transmit the pre-rollback output to the Printer QA Device, by calling the authenticated Write 
function on it again, using the same pre-rollback output. 

If retrying to write the same pre-rollback output fails repeatedly, the System will call the 
StartRollback on the Parameter Upgrade QA Device again, and subsequently calling the 
authenticated Write function on the Printer QA Device using this output. 

25 28.3.3.4 Rollback 

This state indicates a successful deletion (completion) of a transfer sequence. During this state, the 
Parameter Upgrader QA Device verifies the sequence data produced from StartRollBack has been 
correctly written to Printer QA Device, then rolls its count-remaining field to a previous value before 
the transfer request was issued. 

30 28.3.4 Xfer Entry cache 

The Xfer Entry data structure must allow for the following: 
o Stores the transfer state and sequence data for a given transfer sequence, 
o Store all data corresponding to a given transfer, to facilitate a rollback to the previous value 
before the transfer output was generated. 

35 The Xfer Entry cache depth will depend on the QA Chip Logical Interface implementation. For some 
implementations a single Xfer Entry value will be saved. If the Parameter Upgrader QA Device has 
no powersafe storage of Xfer Entry cache, a power down will cause the erasure of the Xfer Entry 
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cache and the Parameter Upgrader QA Device will not be able to rollback to a pre-power-down 
value. 

A dataset in the Xfer Entry cache will consist of the following: 
o Information about the Printer QA Device: 
5 a. Chipld of the device. 

b. FieldNum of the MO field (i.e what was being upgraded), 
o Information about the Parameter Upgrader QA Device: 

a. FieldNum of the MO field used to transfer the count-remaining from. 

o Xfer State- indicating at which state the transfer sequence is. This will consist of: 
10 a. State definition which could be one of the following: - Xfer, 
StartRollBack and deleted (completed). 

b. The value of sequence data fields SEQ_1 and SEQ_2. 

The Xfer Entry cache stores the FieldNum of the count-remaining field of the Parameter Upgrader 
QA Device. 
15 28.3.4.1 Adding new dataset 

A new dataset is added to Xfer Entry cache by the Xfer function. 

There are three methods which can be used to add new dataset to the Xfer Entry cache. The 
methods have been listed below in the order of their priority: 

1 . Replacing existing dataset in Xfer Entry cache with new dataset based on Chipld and 
20 FieldNum of the Ink QA Device in the new dataset. A matching Chipld and FieldNum could 

be found because a previous transfer output corresponding to the dataset stored in the Xfer 
Entry cache has been correctly received and processed by the Parameter Upgrader QA 
Device, and a new transfer request for the same Printer QA Device, same field, has come 
through to the Parameter Upgrader QA Device. 
25 2. Replace existing dataset cache with new dataset based on the Xfer State. If the Xfer State for 
a dataset indicates deleted (complete), then such a dataset will not be used for any further 
functions, and can be overwritten by a new dataset. 
3. Add new dataset to the end of the cache. This will automatically delete the oldest dataset 
from the cache regardless of the Xfer State. 
30 28.4 Upgrading the count-remaining field 

This section is only applicable to the Parameter Upgrader QA Device. 

The transfer of count-remaining is similar to transfer ink-remaining because both involve transferring 
of amounts. Therefore, this transfer uses the XferAmount function. 

The XferAmount function performs additional checks when transferring count-remaining. This 
35 includes checking of the operating parameter field, associated with the count-remaining. They are 
as follows: 
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o The operating parameter value of the upgrading OA Device and the OA Device being 
upgraded must match. 

o The operating parameter field (in both devices) must be upgradeable by one key only, and all 
other keys must have Readonly access. This key which has authenticated ReadWrite 
5 permission to the operating parameter field, must be different to the key that has 

authenticated Read Write permission to the count-remaining field, 
o The data Type for the operating parameter field in the upgrading OA Device must match the 

data Type for the operating parameter field in the OA Device being upgraded. 
28.5 New operating parameter field information 
10 This section is only applicable to the Parameter Upqrader OA Device. 

This field stores the operating parameter value that is copied from the Parameter Upgrader OA 
Device to the operating parameter field being updated in the Printer OA Device. 
This field has a single key associated with it. This key has authenticated ReadWrite permission to 
this field and will be referred to as write-parameter key. 
1 5 Table 299 shows the field information for the new operating parameter field in the Parameter 
Upgrader QA Device. 



Attribute Name 


Value 


Explanation 


Type 


For e.g - 

TYPE_UPGRADE_PRINTSPEED_1 5 a 


Type describing the upgrade. 


KeyNum 


Slot number of the write-parameter key. 


Only the write-parameter key has 
authenticated 

ReadWrite access to this field. 


Non Auth RW 
Perm b 


0 


Non authenticated ReadWrite 
is not allowed to the field. 


Auth RW Perm c 


1 


Authenticated (key based) ReadWrite 
access 

is allowed to the field. 


KeyPerm 


KeyPerms[KeyNum] = 0 


KeyNum is the slot number of the write- 
parameter key which has ReadWrite 
permission to the field. 




KeyPerm s[others= 0 ..7] = 0 


All other keys have ReadOn/y access. 


End Pos 




Set as required. 



a. This is a sample type only and is not included in the Type Map in Appendix A. 
20 b. Non authenticated Read Write permission, 
c. Authenticated Read Write permission. 
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28.6 Different types of transfer 
There can be three types of transfer: 

o Parameter Transfer - This is transfer of an operating parameter value from a Parameter 
5 Upgrader QA Device to a Printer QA Device. This is performed when an upgradeable 

operating parameter is written (for the first time) or changed, 
o Hierarchical refill - This is a transfer of count-remaining value from one Parameter Upgrader 
Refill QA Device to a Parameter Upgrader QA Device, where both QA Devices belong to the 
same OEM. This is typically performed when OEM divides the number of upgrades from one 
10 of its Parameter Upgrader QA Device to many of its Parameter Upgrader QA Devices. 

o Peer to Peer refill - This is a transfer of count-remaining value from one Parameter 

Upgrader Refill QA Device to Parameter Upgrader Refill QA Device, where the QA Devices belong 
to different organisations, say ComCo and OEM. This is typically performed when ComCo divides 
number of upgrades from its Parameter Upgrader QA Device to several Parameter Upgrader QA 
1 5 Device belonging to several OEMs. 

Transfer of count-remaining between peers, and hierarchical transfer of count-remaining, is similar 
to an ink transfer, but additional checks on the transfer reouest is performed when transferring 
count-remaining amounts. This is described in Section 28.4. 1 . 

Transfer of an operating parameter value decrements the count-remaining bv 1 , hence is different 
20 to a ink-transfer. 

Figure 385 is a representation of various authorised upgrade paths in the printing system. 
28.6.1 Hierarchical transfers 

Referring to Figure 385, this transfer is typically performed when count-remaining amount is 
transferred from ComCo's Parameter Upgrader Refill QA Device to OEM's Parameter Upgrader 
25 Refill QA Device, or from QACo's Parameter Upgrader Refill QA Device to ComCo's Parameter 
Upgrader Refill QA Device. 

This transfers are made using the XferAmount function (and not with the XferField described in 
Section 29.1). because count-remaining transfer is similar to fill/refilling of ink amounts, where ink 
amount is replaced bv count-remaining amount. 
30 28. 6.1.1 Keys and access permission 

We will explain this using a transfer from ComCo to OEM. 

There is a count-remaining field associated with the ComCo's Parameter Upgrader Refill QA 
Device. This count-remaining field has two keys associated with: 

© The first key transfers count-remaining to the device from another Parameter Upgrader Refill 
35 QA device(device is higher in the heirachy), fills/refills the device itself. 

© The second key transfers count-remaining from it to other devices (which are lower in the 
heirachy), fills/refills other devices from it. 
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There is a count-remaining field associated with the OEM's Parameter Upgrader Refill QA Device. 

This count-remaining field has a single key associated with: 
o This key transfers count-remaining to the device from another Parameter Upgrader Refilll QA 

device (which is higher or at the same level in the heirachy), fills/refills (upgrades) the device 
5 itself, and additionally transfers count-remaining from it to other devices (which are lower in 

the heirachy), fills/refills (upgrades) other devices from it. 
For a successful transfer of count-remaining from ComCo's refill device to an OEM's refill device, 
the ComCo's refill device and the OEM's refill device must share a common key or a variant key. 
This key is fiil/refill key with respect to the OEM's refill device and it is the transfer key with respect 
10 to the ComCo's refill device. 

For a ComCo to successfully fill/refill its refill device from another refill device (which is higher in the 
heirachy possibly belonging to the QACo), the ComCo's refill device and the QACo's refill device 
must share a common key or a variant key. This key is fili/refiil key with respect to the ComCo's refill 
device and it is the transfer key with respect to the QACo's refill device. 
1 5 28.6.1 .1 .1 Count-remaining field information 

Table 300 shows the field information for an M0 field storing logical count-remaining amounts in the 
refill device, which has the ability to transfer down the heirachy. 



Attribute Name 


Value 


Explanation 


Type 


TYPE_COUNT_REMAINING a 


Type describes that the field is a count- 
remaining field. 


KeyNum 


Slot number of the refill key. 


Only the refill key has authenticated 
ReadWrite access to this field. 


Non Auth RW 
Perm" 


0 


Non authenticated ReadWrite 
is not allowed to the field. 


Auth RW Perm 0 


1 


Authenticated (key based) ReadWrite 
access 

is allowed to the field. 


KeyPerm 


KeyPerms[KeyNum] = 0 


KeyNum is the slot number of the refill 
key, 

which has ReadWrite permission to the 
field. 




KeyPermsfSlot Num of transfer key ] = 1 


Transfer key can decrement the field. 


KeyPerms[others= 0 ..7(except transfer 
key)] = 0 


All other keys have Readonly access. 


End Pos 


Set as required. 


Depends on the amount of logical ink the 
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device can store and storage resolution - 
i.e in picolitres or in microlitres. 



a. Refer to Type Map in Appendix A for exact value. 

b. Non authenticated Read Write permission. 

c. Authenticated Read Write permission. 

5 

28.6.2 Peer to Peer transfer 

Referring to Figure 385, this transfer is typically performed when count-remaining amount is 
transferred from OEM's Parameter Upgrader Refill OA Device to another Parameter Device Refill 
OA Device belonging to the same OEM. 
1 0 28. 6. 2. 1 Keys and access permission 

There is an count-remaining field associated with the refill device. This count-remaining field has a 
single key associated with: 

o This key transfers count-remaining amount to the device from another refill device (which is 
higher or at the same level in the heirachy), fills/refills (upgrades) the device itself, and 
1 5 additionally transfers ink from it to other devices (which are lower in the heirachy), fills/refills 

(upgrades) other devices from it 
This key is referred to as the fili/refiii key and is used for both fiil/refiil and transfer. Hence, this key 
has both ReadWrite and Decrement-Only permission to the count-remaining field in the refill device. 
28.6.2.1 .1 Count-remaining field information 
20 Table 301 shows the field information for an M0 field storing logical count-remaining amounts in the 
refill device with the ability to transfer between peers. 

Table 301 . Field information for ink-remaining field for refill devices transferring between peers 



Attribute 
Name 


Value 


Explanation 


Type 


TYPE_COUNT_REMAINING a 


Type describes that the field is a count-remaining field. 


KeyNum 


Slot number of the refill key. 


Only the refill key has authenticated ReadWrite access 
to this field. 


Non Auth 

RW 

Perm b 


0 


Non authenticated ReadWrite is not allowed to the field. 


Auth RW 
Perm c 


1 


Authenticated (key based) ReadWrite access 
is allowed to the field. 


KeyPerm 


KeyPerms[KeyNum] = 1 


KeyNum is the slot number of the refill key, 
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which has ReadWrite and Decrement permission to the 
field. 




KeyPerms[others= 0 ..7(except 
KeyNum)] = 0 


All other keys have Readonly access. 


End Pos 


Set as required. 


Depends on the amount of logical ink the device can 
store 

and storage resolution - i.e in picolitres or in microlitres. 



a. Refer to Type Map in Appendix A for exact value. 

b. Non authenticated Read Write permission. 

c. Authenticated Read Write permission. 
5 29 Functions 

29.1 XferField 

Input: KeyRef, m Of External, m Of External, Chip Id, Field NumL, 

FieldNumE, InputParameterCheck (Optional), R E , S/G E , Re2 
Output: ResultFlag, Field data, R^, S/G^ 

1 0 Changes: M0 and R L 

Availablity: Parameter Upgrader QA Device 
29.1 .1 Function description 

The XferField is similar to the XferAmount function in that it produces data and signature for 
updating a given M0 field. This data and signature when applied to the appropriate device through 
1 5 the WriteFieldsAuth function, will upgrade the FieldNumE ( M0 field) of a device to the same value as 
FieldNumL of the upgrading device. 

The system calls the XferField function on the upgrade device with a certain FieldNumL to be 
transferred to the device being upgraded The FieldNumE is validated by the XferField function 
according to various rules as described in Section 29.1 .4. If validation succeeds the XferField 
20 function produces the data and signature for subsequent passing into the WriteFieldsAuth function 
for the device being upgraded. 

The transfer field output consists of the new data for the field being upgraded, field data of the two 
sequence fields, and a signature. When a transfer output is produced, the sequence field data in 
SEQ_1 is decremented by 2 from the previous value (as passed in with the input), and the 
25 sequence field data in SEQ_2 is decremented by 1 from the previous value (as passed in with the 
input). 

Additional InputParameterCheck value must be provided for the parameters not included in the 
S/G E , if the transmission between the System and Parameter Upgrader QA Device is error prone, 
and these errors are not corrected by the transmission protocol itself. InputParameterCheck is 
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SHA- 1[FieldNumL \ FieldNumE \ XferValLength \ XferVal], and is required to ensure the integrity of 
these parameters, when these inputs are received by the Parameter Upgrader QA Device. 
The XferField function must first calculate the SHA-1 [FieldNumL | FieldNumE], compare the 
calculated value to the value received (InputParameterCheck) and only if the values match act upon 
the inputs. 

29.1 .2 Input parameters 

Table 302 describes each of the input parameters for XferField function. 



....... ... 

Parameter 


Description 


KeyRef 


For common key input and output signature: KeyRelkeyNum = Slot number of 
the key to be used for testing input signature and producing the output signature. 
S/G E produced using K Ke yRef.keyNum by the QA Device being upgraded. SIGout 
produced using KKeyRef.keyNum for delivery to the QA Device being upgraded. 
KeyRef.useChipId = 0 




For variant key input and output signatures: KeyRelkeyNum = Slot number of 
the key to be used for generating the variant key. S/G E produced using a variant 
of KKeyRef.keyNum by the OA Device being upgraded. SIGout produced using a 
variant of K Ke yRef keyNumfor delivery to the QA Device being upgraded. 
KeyRef.useChipId = 1 KeyRef.chipId = Chipld of the device which generated 
o/v3Eana win receive o/oour. 


MoOfExternai 


All 16 words of M o of the QA Device being upgraded 


m Of External 


All 16 words of M1 of the QA Device being upgraded. 


Chipld 


Chipld of the QA Device being upgraded. 


FieldNumL 


mo field number of the local (updating) device. The data stored in this field will be 
copied from the upgrading device. 


FieldNumE 


mo field number of the QA Device being upgraded. This field will be updated to 
the value stored in FieldNumL within the upgrading device. 


Re 


External random value used to verify input signature. This will be the R from the 
input signature generator (i.e device generating SIGe). The input signal generator 
in this case, is the device being upgraded or a translation device. 


Re2 


External random value used to produce output signature. This will be the R 
obtained by calling the Random function on the device which will receive the 
57Goutfrom the XferField function. The device receiving the SIG om \n this case, is 
the device being upgraded or a translation device. 
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S/G E 


External signature required for authenticating input data. The input data in this 




case, is the output from the Read function performed on the device being 




upgraded. 




A correct S/G E = SIG Key Ref(Data | Re | RJ. 



29. 1.2.1 Input signature verification data format 

Refer to Section 27.1 .2.1 . 
29.1 .3 Output parameters 

Table 303 describes each of the output parameters for XferField function. 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned here. 
See Section 12.1, Table 292 and Table 303. 


FieldSelect 


Selection of fields to be written 

In this case the bit corresponding to SEQ_1 , SEQ_2 and to 
FieldNumE are set to 1 . 
All other bits are set to 0. 


FieldVal 


Updated data words for sequence data field and FieldNumE for OA 
Device being upgraded. 
Starts with LSW of lower field. 

This must be passed as input to the WriteFieldsAuth function of the OA 
Device being upgraded. 


R\_2 


Internal random value required to generate output signature This must 
be passed as input to the WriteFieldsAuth function or Translate 
function of the QA Device being upgraded. 


S/G out 


Output signature which must be passed as an input to the 
WriteFieldsAuth function or Translate function of the QA Device being 
upgraded. 

SIG out = SIG Ke yRef{data | Rl2 I Re2> as per Figure 373 
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Table 303. Result Flag definitions for XferField 



ReultFlag Definition 


Description 


CountRemainingFieldlnva 
lid 


The count- remaining field in Upgrading OA Device is invalid. 


Fiel d N u m E KeyPer m 1 n val i 
d 


The upgrade field in the QA Device being upgraded doesn't have the 
correct authenticated permission. 


NoUpgradesRemaining 


The count-remaining field assocaited with the upgrade field in the 
Upgrading QA Device doesn't have any more upgrades left. 



29. 1.3.1 Output signature generation data format 
5 Refer to Section 27.1 .3.1 . 

29.1 .4 Function sequence 

The XferField command is illustrated by the following pseudocode: 
Accept input parameters-KeyRef, MOOfExternal, MIOfExternal, Chipld, FieldNumL, 
FieldNumE, Re, SIG Ei Re 2 

10 

#Generate message for passing Into ValidateKeyRefAndSignature 
function 

data <- (RWSense|MSelect|KeyIdSelect|ChipId|WordSelect |M0|M1) 
# Refer to Figure 382. 

15 



# Validate KeyRef, and then verify signature 
ResultFlag = ValidateKeyRef AndSignature (KeyRef , data, R E , R L ) 

20 If (ResultFlag * Pass) 

Output ResultFlag 
Return 
Endlf 

25 # Validatate FieldNumE 

# FieldNumE is present in the device being upgraded 
PresentFlagFieldNumE <— GetFieldPresent (MIOfExternal , FieldNumE ) 

# Check FieldNumE present flag 
30 If (PresentFlagFieldNumE * 1) 
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ResultFlag <- FieldNumElnvalid 
Output ResultFlag 
Return 
Endlf 



# Check Seq fields exist and get their Field Number 

# Get Seqdata field SEQ_1 for the device being upgraded 
Xf erSEQ_lFieldNum<- GetFieldNum (MIOf External , SEQ_1) 

# Check if the Seqdata field SEQ_1 is valid 
If (Xf erSEQ_lFieldNum invalid) 

ResultFlag «- SeqFieldlnvalid 
Output ResultFlag 
Return 
Endlf 

# Get Seqdata field SEQJZ for the device being upgraded 
Xf erSEQ_2FieldNum<- GetFieldNum (MIOf External , SEQ_2 ) 

# Check if the Seqdata field SEQ_2 is valid 
If (XferSEQ_2FieldNum invalid) 

ResultFlag <r- SeqFieldlnvalid 
Output ResultFlag 
Return 
Endlf 



#Check write permission for FieldNumE 

PermOKFieldNumE <- CheckFieldNumEPerm (MIOf External , FieldNumE) 
If (PermOKFieldNumE * 1) 

ResultFlag <r- FieldNumEWritePerm Invalid 

Output ResultFlag 

Return 
Endlf 



872 



#Check that both SeqData fields have Decrement -Only permission 
with the same key 

#that has write permission on FieldNumE 

PermOKXf erSeqData <- CheckSeqDataFieldPerms (MIOf External , 

XferSEQ_lFieldNum, 
Xf erSEQ_2FieldNum, FieldNumE) 
If ( PermOKXf erSeqData * 1) 

ResultFlag <r- SeqWritePerm Invalid 

Output ResultFlag 

Return 
Endlf 



# Get SeqData SEQ_1 data from device being upgraded 
GetFieldDataWords (Xf erSEQ_lFieldNum / 

Xf erSEQ_lDataFromDevice , MOOf External , MIOf External ) 

# Get SeqData SEQ_2 data from device being upgraded 
GetFieldDataWords (Xf erSEQ_2FieldNum # 

Xf erSEQ_2DataFromDevice , 
MOOf External , MIOf External ) 



# FieldNumL (upgrade value) is a valid field in the upgrading device 
PresentFlagFieldNumL <r- GetFieldPresent (Ml , FieldNumL) 
If (PresentFlagFieldNumL * 1) 

ResultFlag <- FieldNumLlnvalid 

Output ResultFlag 

Return 
Endlf 



#Get the CountRemaining field associated with the upgrade value 
field 
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# The CountRemaining field is the next higher field from the 
upgrade value field 

FieldNumCountRemaining*— FieldNumL + 1 

5 # FieldNumCountRemaining is a valid field in the upgrading device 

Pre sent FlagFieldNumCount Remaining 
<r- GetFieldPresent (Ml, FieldNumCountRemaining) 
If (PresentFlagFieldNumCountRemaining * 1) 
ResultFlag <- CountRemainingField Invalid 
10 Output ResultFlag 

Return 
Endlf 

#Check permission for upgrade value field. Only one key (different 
15 # from KeRef.keyNum) has write permissions to the field and no key 

has decrement permissions . 

CheckOK <- CheckUpgradeKeyForFie Id (FieldNumL, Ml , KeyRef) 
If (CheckOK * 1) 

ResultFlag <- Field NumEKeyPerm In valid 
20 Output ResultFlag 

Return 
Endlf 

#Find the type attribute for FieldNumE 
25 TypeFieldNumE <— FindFieldNumType (MIOf External , FieldNumE) 

#Find the type attribute for FieldNumL (upgrade value) 
TypeFieldNumL <— FindFieldNumType (Ml , FieldNumL) 

If (TypeFieldNumE * TypeFieldNumL) 
30 ResultFlag <- TypeM is match 

Output ResultFlag 

Return 
Endlf 

35 
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# Check permissions for Count Remaining field 

# Check upgrades are available in the CountRemaining field of the 

# upgrading device i.e value of CountRemaining is non-zero 
positive number 

CountRemainingOK <-CheckCountRemaining (FieldNumCount Remaining, MO , 
Ml) 

If (CountRemainingOK * 1) 

ResultFlag <- Nollpgrades Remaining 

Output ResultFlag 

Return 
Endlf 



#Get the size of the FieldNumL (upgrade value) 
If(FieldNumL = 0) 

FieldSizeOf FieldNumL*- MaxWordlnM- Ml [FieldNumL] .EndPos 
Else 

FieldSizeOfFieldNumL<- Ml [FieldNumL- 1] .EndPos- 
Ml [FieldNumL] .EndPos 
Endlf 

#Get the size of the FieldNumE (field being updated) 
If (FieldNumL = 0) 

FieldSizeOf FieldNumE*- MaxWordlnM- MlOf External [FieldNumE - 
1] .EndPos 
Else 

FieldSizeOf FieldNumE*- MlOf External [FieldNumE- 1] .EndPos 

- MlOf External [FieldNumL] .EndPos 

Endlf 

# Check whether the device being upgraded can hold the upgrade 
value from 

# FieldNumL 

If (FieldSizeOf FieldNumE < FieldSizeOf FieldNumL) 
ResultFlag <- FieldNumESizelnsufficient 
Output ResultFlag 
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Return 
Endlf 



# All checks complete 

# Generate Seqdata for SEQ__1 and SEQ_2 fields 

Xf erSEQ_lDataToDevice = Xf erSEQ_lDataFromDevice - 2 
Xf erSEQ_2DataToDevice = Xf erSEQ_2DataFromDevice - 1 

# Add DataSet to Xfer Entry Cache 

AddDataSetToXf erEntryCache (Chipld, FieldNumE, FieldNumL, 
Xf erSEQ__lDataFromDevice, Xf erSEQ_2DataFromDevice) 

^Decrement Count Remaining field by one 
DecrementField ( FieldNumCountRemaining , MO ) 

#Gefc the upgrade value words from FieldNumE of the upgrading 
device 

GetFieldDataWords (FieldNumL, UpgradeValue, MO , Ml) 

#Generate new field data words for FieldNumE. The upgrade value is 

copied to 

FieldDataE 

FieldDataE^- UpgradeValue 

# Generate FieldSelect and FieldVal for SeqData field SEQ_1, SEQJ2. 
and 

# FieldDataE. . . 
CurrentFieldSelect<— 0 
FieldVal <- 0 

GenerateFieldSelectAndFieldVal ( FieldNumE , FieldDataE , 
XferSEQ_lFieldNum, Xf erSEQ_lDataToDe vice, Xfer SEQ_2FieldNum, 
Xf erSEQ_2DataToDevice , 
FieldSelect, FieldVal) 

^Generate message for passing into Generates ignature function 
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data <- (RWSense|FieldSelect|ChipId|FieldVal)# Refer to Figure 373. 
#Create output signature for FieldNumE 
SIG 0 ut<— Generates ignature (KeyRef , data, R^ , R E2 ) 
Update R^ to R L3 
5 ResultFlag <— Pass 

Output ResultFlag, FieldSelect , FieldVal , Rls ,SIG ou t 

Return 

Endlf 

29. 1.4.1 CountRemainingOK 
1 0 CheckCountRemainingFieldNumL(FieldNumCountRemaining, M1,M0) 

This functions checks permissions for CountRemaining field and also checks 
that upgrades are available in the CountRemaining field of the upgrading device. 
AuthRW <- Ml [FieldNumCountRemaining] .AuthRW 
NonAuthRW <— Ml [FieldNumCountRemaining] .NonAuthRW 
15 DOForKeys <— mi [FieldNumCountRemaining] . DOFor Keys [KeyNum] 

Type <— m 1 [FieldNumCountRemaining] .Type 

If (AuthRW = 1 a NonAuthRW = 0 a (DOForKeys = 1a (Type = 
TYPE_COUNT_REMAINING ) 

PermOK <—l 
20 Else 

PermOK <- 0 

Return PermOK 
Endlf 

#Get the count -remaining value from the upgrading device 
25 GetFieldDataWords (FieldNumCountRemaining, CountRemaining Value, MO , Ml 

) 

If (CountRemainingValue <= 0) 

PermOK <— 0 

Return PermOK 
30 Endlf 

PermOK <- 1 
Return PermOK 



35 
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29.2 RollBackField 

Input: KeyRef, m OfExternal, m OfExternal, Chipld, FieldNumL, 

FieldNumE, InputParameterCheck (optional), R E , S/G E 
Output: ResultFlag 
5 Changes: M0 and R L 

Availablity: Parameter Upgrader QA Device 
29.2.1 Function description 

The RollBackField function is very similar to the RollBackAmount function, the only difference being 
that the RollBackField function adjusts the value of the count-remaining field associated with the 
1 0 upgrade value field of the upgrading device, instead of the upgrade value field itself. A successful 
rollback, increments the count-remaining by 1 . 

The Parameter Upgrader QA Device checks that the Printer QA Device didn't actually receive the 
transfer message correctly, by comparing the sequence data field values read from the device with 
the values stored in the Xfer Entry cache. The sequence data field values read must match what 
1 5 was previously written using the StartRollBack function. After all checks are fulfilled, the Parameter 
Upgrader QA Device adjusts its FieldNumL. 

Additional InputParameterCheck value must be provided for the parameters not included in the 
S/G E , if the transmission between the System and Parameter Upgrader QA Device is error prone, 
and these errors are not corrected by the transimission protocol itself. InputParameterCheck is 
20 SHA-1 [FieldNumL \ FieldNumE ], and is required to ensure the integrity of these parameters, when 
these inputs are received by the Parameter Upgrader QA Device. 

The RollBackField function must first calculate the SHA-1 [FieldNumL \ FieldNumE], compare the 
calculated value to the value received (InputParameterCheck) and only if the values match act upon 
the inputs. 
25 29.2.2 Input parameters 

Table 305 describes each of the input parameters for RollBackField function. 



Parameter 


Description 


KeyRef 


For common key input signature: KeyRef.keyNum = Slot number of 
the key to be used for testing input signature. S/G E produced using 
KKeyRef.keyNum by the QA Device being upgraded. KeyRef.useChipId = 
0 




For variant key input signature: KeyRef.keyNum = Slot number of the 
key to be used for generating the variant key. S/G E produced using a 
variant of KKeyRef.keyNum by the QA Device being upgraded. 
KeyRef.useChipId = 1 KeyRef.chipId = Chipld of the device which 
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generated S/G E . 


m OfExternal 


16 words of mo of the QA Device being upgraded which failed to 
upgrade. 


m OfExternal 


16 words of mi of the QA Device being upgraded which failed to 
upgrade. 


Chipfd 


Chipld of the QA Device being upgraded which failed to upgrade. 


FieldNumL 


mo field number of the local (upgrading) device whose value could not 
be copied to the device being upgraded. 


FieldNumE 


mo field number of the QA Device being upgraded to which the 
upgrade value in FieldNumL couldn't be copied. 


Re 


External random value used to verify input signature. This will be the 
R from the input signature generator (i.e device generating SIGe). 
The input signal generator in this case, is the device which failed to 
upgrade or a translation device. 


S/G e 


External signature required for authenticating input data. The input 
data in this case, is the output from the Read function performed on 
the device which failed to upgrade. A correct S/G E = SIG Ke yRef(Data | 
Re I RJ. 



29. 2. 2. 1 Input signature generation data format 

Refer to Section 27.1 .2.1 for details. 
29.2.3 Output parameters 
5 Table 306 describes each of the output parameters for RollBackField. 



Parameter 


Description 


ResultFlag 


Indicates whether the function completed successfully or not. If it did 
not complete successfully, the reason for the failure is returned 
here. See Section 12.1 , Table 292, Table 304 and Table 295. 



Function sequence 

The RollBackField command is illustrated by the following pseudocode: 
Accept input parameters -KeyRef , MOOf External , MIOf External , 
Chipld, FieldNumL, FieldNumE, R e ,SIGe 



^Generate message for passing Into Genera teSignatu re function 
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29.2.4 

10 



data <r- (RWSense |MSelect | KeyldS elect | Chipld | WordSelect |M0|M1) 
# Refer to Figure 382. 



# Validate KeyRef, and then verify signature 

ResultFlag = ValidateKeyRef AndSi gnat ure (KeyRef , data, R E , R L ) 

If (ResultFlag * Pass) 

Output ResultFlag 

Return 
Endlf 



# Check Seq fields exist and get their Field Number 

# Get Segdata field SEQ__1 num for the device being upgraded 
XferSEQ_lFieldNum<- Get FieldNum (MIOf External , SEQ_1) 

# Check if the Seqdata field SEQ_1 is valid 
If (XferSEQ_lFieldNum invalid) 

ResultFlag <- SeqFieldlnvalid 
Output ResultFlag 
Return 
Endlf 

# Get Seqdata field SEQ__2 num for the device 
Xf erSEQ_2FieldNum<- Ge t FieldNum (MIOf External , 

# Check if the Seqdata field SEQ_2 is valid 
If (XferSEQ_2FieldNum invalid) 

ResultFlag <r- SeqFieldlnvalid 
Output ResultFlag 
Return 
Endlf 



# Get SeqData SEQ__1 data from device being upgraded 
GetFieldDataWords (XferSEQ_l FieldNum, 

Xf erSEQ_lDataFromDevice , MOOf External , MIOf External ) 



being upgraded 
SEQ_2 ) 
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# Get SeqData SEQ_2 data from device being upgraded 
GetFieldDataWords (Xf erSEQ_2FieldNum, 

X f er SEQ_2 DataFromDevi c e , 
5 MOOf External , MIOf External ) 

# Generate Segdata for SEQ_1 and SEQ_2 fields with ,the data that 
is read 

Xf erSEQ_lData = Xf erSEQ_lDataFromDevice + 1 
10 Xf erSEQ_2Data = Xf erSEQ_2DataFromDevice + 2 



# Check Xfer Entry in cache is correct - dataset exists, Field 
data 

15 # and sequence field data matches and Xfer State is correct 

XferEntryOK <- CheckEntry (Chipld, FieldNumE, FieldNumL, 
XferSEQ_lData, Xf erSEQ_2Data) 

If( XferEntryOK= 0) 
20 ResultFlag <- RollBacklnvalid 

Output ResultFlag 

Return 
Endlf 

25 # Jncrement associated Count Remaining by 1 

IncrementCountRemaining ( FieldNumCount Remaining) 

# Update XferState in DataSet to complete/deleted 
UpdateXf erStateToComplete (Chipld, FieldNumE) 
ResultFlag <— Pass 

30 Output ResultFlag 

Return 

Example sequence of operations 
30 Concepts 

The QA Chip Logical Interface interface devices do not initiate any activities themselves. Instead 
35 the System reads data and signature from various untrusted devices, and sends the data and 
signature to a trusted device for validation of signature, and then uses the data to perform 
operations required for printing, refilling, upgrading and key replacement. The system will therefore 
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be responsible for performing the functional sequences required for printing, refilling, upgrading and 
key replacement. It formats all input parameters required for a particular function, then calls the 
function with the input parameters on the appropriate OA Chip Logical Interface instance, and then 
processes/stores the output parameters from the function appropriately. 
5 Validation of signatures is achieved by either of the following schemes: 

o Direct - the signature produced by an untrusted device is directly passed in for validation to 
the trusted device. The direct validation requires the untrusted device to share a common key 
or a variant key with the trusted device. Refer to Section 7 for further details on common and 
variant keys. 

10 o Translation - the signature produced by an untrusted is first validated by the translating 
device, and a new signature of the read data is produced by the translation device for 
validation by the trusted device. Several translation device may be chained together - the first 
translation device validates the signature from the untrusted device, and the last translation 
device produces the final signature for validation by the trusted device. The translation device 

15 must share a common key or a variant key with the trusted/untrusted device and among 

themselves, if several translation devices are chained together for signature validation. 
30.1 Representation 

Each functional sequence consists of the following devices (refer to Section 4.3): 
o System. 

20 o A trusted QA Device - which may be a system trusted QA Device, or an Parameter Upgrader 
QA Device, or a Ink Refill QA Device, or a Key Programmer QA Device depending on the 
function performed. This device is referred to as device A. 
o An untrusted QA Device - which may be a Printer QA Device, or an Ink QA Device. This 
device is referred to as device B. 
25 o A translation QA Device will be used if a translation scheme is used to validate signatures. 
This device is referred to as device C. 
The command sequence produced by the system for further sequences will be documented as 
shown in Table 307. 

Table 307. Command sequence representation 

30 



Sequence 
No 


Function 


Parameters 


Sequence order 


Device.FunctionName 


Input Parameters and their 
values. 


Output parameters and their 
description. 
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Therefore, a typical direct signature validation sequence can be represented by 
Figure 386 and Table 308. 

For a direct signature to be used, A and B must share a common or a variant key 
5 i.e B.Km = A.K^ or B.Km = FormKeyVariant(A.Kn2 , B.ChipId). 



Table 308. Command sequence for direct signature validation 



Sequence 

NO 


Function 


Parameters 


1 
i 


H.r\anuom 


None 






r a =rl 


2 


B.Read 


KeyRef = n1 , SigOnly = 0, MSelect = Any one M, KeyldSelect = 
0, WordSelectForDesiredM = Any one word in the selected M, 
RE = R A 






If ResultFlag = Pass then MWords = 
SelectedWordsOfSelectedMs as per input [MSelect] and 
[WordSelectForDesiredM], R B = R L , SIG B = SIGout Refer to 
Section 15.3:1. 


3 


A.Test 


KeyRef = n2, DataLength = Length of MWords in words 
Preformatted as per Section 16.1 , Data = MWords preformatted 
as per Section 16.1 , RE =R B , SIGE = SIG B 






ResultFlag = Pass/Fail 



10 
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A typical signature validation using translation can be represented by 

Figure 387 and Table 309. 

For validating signatures using translation: 

• A and C must share a common or a variant key 

5 i.e C.Kn3 = A.Kn2 or C.K^ = FormKeyVariant(A.Kn2 , C.ChipId). 

• B and C must share a common or a variant key 

i.e C.K^ = B.K n1 or B.Km = FormKeyVariantfC.K,*, B.ChipId). 

Table 309. Command sequence for signature validation using translation 

10 



Sequence 
No 


Function 


Parameters 


1 


C. Random 


None 


Rc = RL 


2 


B.Read 


KeyRef = n1 , SigOnly = 1 or 0, MSelect = any, KeyldSelect = 
any, WordSelectForDesiredM = any, RE= Rc 


If ResultFlag = Pass then MWords = 
SelectedWordsOfSelectedMs as per input [MSelect] and 
[WordSelectForDesiredM], R B = Ru SIG B = SIGout Refer to 
Section 15.3.1. : 


3 


A.Random 


None 


R A =RL 


4 


C. Translate 


InputKeyRef =n2, DataLength = Length of MWords in words 
Preformatted as per Section 17.1, Data = MWords preformatted 
as per Section 17.1, RE= R B , SIGE = SIG B , OutputKeyRef = 
n3, RE2 = R A 


If ResultFlag = Pass then Rci= Ru>. SIG C = SIGOut Refer to 
Section 15.3.1 


5 


A. Test 


KeyRef = n2, DataLength = Length of MWords in words 
Preformatted as per Section 16.1, Data = MWords preformatted 
as per Section 16.1, RE=Rci, SIGE = SIG C 


ResultFlag = Pass/Fail 



31 In field use 

This section covers functional sequences for printer and ink OA Devices, as they perform their 
usual function of printing. 
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31 .1 Startup sequence 

At startup of any operation (a printer startup or an upgrade startup), the system determines the 
properties of each QA Device it is going to communicate with. These properties are: 

• Software version of the QA Device. This includes SoftwareReleaseldMajor and Soft- 
wareReleaseldMinor. The SoftwareReleaseldMajor identifies the functions available in the 
QA Device. Refer to Section 13.2 for details. 

• The number of memory vectors in the QA Device. 

• The number of keys in the QA Device. 

• The Chipld of the QA Device. 

The properties allow the system to determine which functions are available in a given QA Device, 
as well as the value of input parameters required to communicate with the QA Device. 
Table 310 shows the startup sequence. 

Table 310. Startup command sequence 



Sequence No 


Function 


Command 


1 


B.Getlnfo 


None 


Major release identifier of the QA Device = 
SoftwareReleaseldMajor, Minor release identifier of the QA 
Device= SoftwareReleaseldMinor, Number of memory vectors 
in the QA Device= NumVectors, Number of keys in the QA 
Device= NumKeys, Id of the QA Device = Chipld 0 = 
VarDataLen No VarData in case of an ink or printer QA Device 



31 .1 .1 Clearing the preauthorisation field 

Preauthorisation of ink is one of the schemes that a printer may use to decrement logical ink as 
physical ink is used. This is discussed in details in Section 31 .4.3. 

If the printer uses preauthorisation, the system must read the preauthorisation field at startup. If the 
preauthorisation field is not clear, then the system must apply (decrement) the preauth amount to 
the corresponding ink field, by performing a non-authenticated write of the decremented amount to 
the appropriate ink field, and then clear the preauthorisation field by performing an authenticated 
write to the preauthorisation field. 
31 .2 Presence Only authentication 

The purpose of presence only authentication is to determine whether the printer should or shouldn't 
work with the ink cartridge. 
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31 .2.1 Without data interpretation 

This sequence is performed when the printer authenticates the ink cartridge. The authentication 
consists of verifying a signature generated by the untrusted ink OA Device (in the ink cartridge) 
using the system's trusted OA Device. 
5 For signature to be valid, the trusted OA Device (A) and the untrusted ink QA Device (B) must share 
a common or a variant key i.e B.K^ = A.K^or B.K^ = FormKeyVariant(A.Kn2 , B.ChipId). 
A single word of a single M is read because the system is only interested in the validity of signature 
for a given data. 

If the printer wants to verify the signature and doesn't require any data from the ink cartridge 
1 0 (because it is cached in the printer), then the printer calls the Read function with SigOnly set to 1 . 
The Read returns only the signature of the data as requested by the input parameters. The printer 
then sends its cached data and signature (from the Read function) to its trusted QA Device for 
verification. The printer may use this signature verification scheme if it has read the data previously 
from the ink QA Device, and the printer knows that the data in the ink QA Device has not changed 
1 5 from value that was read earlier by the printer. 

Table 31 1 shows the command sequence for performing presence only authentication requiring 
both data and signature. 



Seq 
No 


Function 


Parameters 


1 


A. Random 


None 






Ra=RL 


2 


B.Read 


KeyRef = n1 , SigOnly = 0, MSelect = Any one M, KeyldSelect = 0, 
WordSelectForDesiredM = Any one word in the selected M, RE= R A 






If ResultFlag = Pass then M Words = SelectedWordsOfSelectedMs as 
per input [MSelect] and [WordSelectForDesiredM], Re = Ru SIG B = 
SIGout Refer to Section 1 5.3.1 . 


3 


A.Test 


KeyRef = n2, DataLength = Length of MWords in words preformatted 
as per Section 16.1 , Data = MWords preformatted as per Section 16.1 1 
RE=Rb, SIGE = SIG B 






ResultFlag = Pass/Fail 



20 

31 .2.2 With data interpretation 

This sequence is performed when the printer reads the relevant data from the untrusted QA Device 
in the ink cartridge. The system validates the signature from the external ink QA Device, and then 
uses this data for further processing. 
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For signature to be valid, the trusted OA Device (A) and the untrusted OA Device (B) must share a 
common or a variant key i.e B.Km = A.K^or B.Km = FormKeyVariant(A.Kn2 , B.ChipId). 
The data read assists the printer to determine the following before printing can commence: 

• Which fields in M o store logical ink amounts in the ink OA Device. 

5 • The size of the ink fields in the ink OA Device. Refer to Section 8.1 .1 .1 . 

• The type of ink. 

• The amount of ink in the field. 

Table 312 shows the command sequence for performing presence only authentication (with data 
interpretation). 



Seq 
No 


Function 


Parameters 


1 


A. Random 


None 


r a = rl 


2 


B.Read 


KeyRef = n1, SigOnly = 0, MSelect = 0x03(indicates MO and M1), 
KeyldSelect = OxFF (Read all Keylds), WordSelectForDesiredM (for 
M0 )= OxFFFF (Read all 16 M oWords), WordSelectForDesiredM (for M1 )= 
OxFFFF(Read all 16 M1 words), RE= R A 


If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs as 
per input [MSelect] and [WordSelectForDesiredM], All 16 words of M0 
and mi . R B = RL SIG B = SIGout Refer to Section 15.3.1 


3 


A.Test 


Input Key = n2, DataLength = Length of MWords in words Preformatted 
as per Section 16.1 , Data = MWords prefonnatted as per Section 16.1 , 
RE =R B , SIGE = SIG B 


ResultFlag = Pass/Fail 



31.2.2.1 Locating ink fields and determining ink amounts remaining 

Before printing can commence, the printer must determine the ink fields in the ink cartridge so that it 
1 5 can decrement these fields with the physical use of ink. The printer must also verify that the ink in 
the ink cartridge is suitable for use by the printer. 

This process requires reading data from the ink OA Device and then comparing the data to what is 
required. To perform the comparison the printer must store a list for each ink it uses. 
The ink list must consist of the following: 
20 • Ink Id - A identifier for the ink 

• Keyld - The Keyld of the key used to fill/refill this ink. 

• Type - This is the type attribute of the ink. 
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The ink list stored in the printer is shown in Table 313. 



Ink Id 


Keyld 


Type 


1- represents black ink 


1 - represents Keyld of 

Network_OEM_lnkFill/Refill 

Key 6 


0x55 

TYPE_REGU LAR_BLACK_I N K a 


2- represents cyan ink 


1- represents Keyld of 
Network_OEM_l nkFill/Refill 
Key" 


0x9F 

TYPE_HIGHQUALITY_CYAN_INK 

a 


3- represents magenta 
ink 


1 - represents Keyld of 

Network_OEM_lnkFill/Refill 

Key" 


0x9A 

TYPE_HIGHQUALITY_MAGENTA 
_INK a 


4- represents yellow 
ink 


1- represents Keyld of 

Network_OEM_lnkFill/Refill 

Key" 


0x9C 

TYPE_HIGHQUALITY_YELLOW_l 
NK a 



5 a. These Types are only used as an example, 
b. These Keylds are only used as an example. 
The printer will perform a Read of the ink QA Device's MO, M1 and Keylds to determine the 
following: 

o The correct ink field ( M o field) in the ink QA Device. 
10 o The amount of ink-remaining in the field. 

The ink QA Device's M1 and Keyld helps the printer determine the location of the ink field and ink 
QA Device's MO and M1 helps determine the amount of ink-remaining in the field. 
31.2.2.2 Field Num FindFieldNumfkeyldRequired, typeRequired) 

This function returns a Fie/dNum of an MO field, whose authenticated ReadWrite access key's 
1 5 Keyld is keyldRequired, and whose Type attribute matches typeRequired. If no matching field is 
found it returns a FieldNum = 255. This function must be available in the printer system so that it 
can determine the ink field required by it. 
The function sequence is described below. 

# Get total number of fields in the ink QA Device 
20 FieldSize [16] <- 0 # Array to hold FieldSize assuming there are 16 

fields 

NumFields*- FindNumberOf FieldsInMO (Ml , FieldSize) # Refer to 
Section 19.4.1. 
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# Loop through Keylds read assuming all Keylds have been read from 
ink QA Device 
For i <— 0 to 7 

#Check if Keyld read matches 



If (Keyld l = keyldRequired # Matching Keyld found 

KeyNum i # Get the KeyNum of the matching Keyld 

# Now look through the field to check which field has 
#write permissions with this KeyNum 

For j <— 0 to NumOfFields 

AuthRW <- M1 [j] .AuthRW # Isolate AuthRW for field 

# Check authenticated write is allowed to the field 

If (AuthRW = 1) 

KeyNumj<- M itjl .KeyNum # Isolate KeyNum of the field 
• Typej ^Mitj].Type #Islotate Type attribute of the field 
# Check if Key is write key for the field and type of 

Ink Id#2 

If (KeyNum = KeyNum-,) a (Typej = typeRequired) 

FieldNum <— j 

return FieldNum 
Endlf 
Endlf 

EndFor # Loop through to next field 
FieldNum <- 2 55 # Error - no field found 
return FieldNum 
Endlf 

EndFor # Loop through to next Keyld 

For e.g if the printer wants to find an ink field that matches Ink ld#2 (from Table 
31 3) in the ink QA Device, it must call the function FindFiefdNum with 
keyldRequired = Keyld of Network_OEM_lnkFill/Refill Key and typeRequired = 
TYPE_HIGHQUALITY_CYANJNK. 
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31.2.2.3 Ink-remaining amount 

This can be determined by using the function GetFieldDataWords(FieldNum,FieldDataQ, M0,M1) 
described in Section 27.1 .4.14. FieldNum must be set to the value returned from function in Section 
31 .2.2.2. FieldData returns the ink-remaining amount. 
5 The function GetFieldDataWords(FieldNum,FieldDataQ, M0,M1) must be implemented in the printer 
system. 

31 .3 Presence Only authentication through the Translate function 
This sequence is performed when the printer reads the data from the untrusted ink QA Device in the 
ink cartridge but uses a translating QA Device to indirectly validate the read data. The translating 
10 QA Device validates the signature using the key it shares with the untrusted QA Device, and then 
signs the data using the key it shares with the trusted QA Device. The trusted QA Device then 
validates the signature produced by the translating QA Device. 
For validating signatures using translation: 

• A and C must share a common or a variant key 

15 i.e C.Kn 3 = A.K^or C.K^ FormKeyVariant(A.Kn2 , C.ChipId). 

• B and C must share a common or a variant key 

i.e C.Kn 2 = B.Kni or B.K^ = FormKeyVarian^CK^, B.ChipId). 

Table 314 shows a command sequence for presence only authentication using translation 



Seq 
No 


Function 


Parameters 


1 


C. Random 


None 






Rc= RL ■■■:r-\: ■ •• : ;VM ; % : • -■ : ' - : . ;^f^r 


2 


B.Read 


KeyRef = n1 , SigOnly = 1 or 0, MSelect = any M, KeyldSelect = 0, 
WordSelectForDesiredM = any, RE= Rc 






If ResultFlag = Pass then MWords = Selected WordsOf Selected Ms as 
per input [MSelect] and [WordSelectForDesiredM], Rb = Rl, SIG B = 
SIGout Refer to Section 15.3.1 


3 


A.Random 


None 






R A = RL 


4 


C. Translate 


InputKeyRef =n2, DataLength = Length of MWords in words 
Preformatted as per Section 1 7.1 , Data = MWords preformatted as per 
Section 17.1 , RE= Re, SIGE = S!G B , OutputKeyRef = n3, RE2 = R A 






If ResultFlag = Pass then Rd=RLl, SIG C = SIGOut Refer to Section 
15.3.1 
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5 


A.Test 


KeyRef = n2, DataLength = Length of MWords in words preformatted 
as per Section 16.1, Data = MWords preformatted as per Section 16.1, 
RE=Rci,SIGE = SIG c 


ResultFlag = Pass/Fail 



31 .4 Updating the ink-remaining 

This sequence is performed when the printer is printing. The ink OA Device holds the logical 
amount of ink-remaining corresponding to the physical ink left in the cartridge. This logical ink 
5 amount must decrease, as physical ink from the ink cartridge is used for printing. 
31 .4.1 Sequence of update 

The primary question is when to deduct the logical ink amount - before or after the physical ink is 
used. 

a. Print first (use physical ink) and then update the logical ink. If the power is cut off after a 
1 0 physical print and before a logical update, then the logical update is not performed. 

Therefore, the logical ink-remaining is more than the physical ink-remaining. Performing 
repeated power cuts will increase the differential amount, and finally any physical ink could 
be used to refill the OA Device. 

b. Update the logical ink and then print (use physical ink). This is better than 

1 5 (a) because other physical inks cannot be used. However, if a problem occurs during printing, 

after the logical amount has already been deducted, there will be a disparity between logical 
and physical amounts. This might result in the printer not printing even if physical ink is 
present in the ink cartridge. The amount of disparity can be reduced by increasing the 
frequency of updating logical ink i.e update after each line instead of after each page. 
20 c. Preauthorise logical ink. Preauthorise certain amount of ink (depends on the frequency of 

logical updates) before print and clear it at the end of printing. If power is cut off after a page 
is printed, then on start up, the printer reads the preauthorisation field, if it has not been 
cleared, it applies the preauth amount to the ink-remaining amount, and then clears the 
preauthorisation field. 
25 31 .4.2 Basic update 

Some printers may use one of methods described in Section 31 .4.1 (a) or (b) to update logical ink 
amounts in the ink QA Device. This method of updating the ink is termed as a basic update. The 
decremented amount is written to the appropriate ink field (which has been previously determined 
using Section 31 .2.2) in M0 - The printer verifies the write, by reading the signature of the written 
30 data, then passing it to the Test function of the trusted QA Device. 

For signature to be valid, the trusted QA Device (A) and ink QA Device (B) must share a common or 
a variant key i.e B.Km = A.K^or B.Km = FormKeyVariant(A.Kn2 , B.ChipId). 
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Table 315. Command sequence for updating the ink-remaining (basic) 



Seq 
No 


Function 


Parameter 


1 


B.WriteFields 


VectNum = 0, FieldSelect =Se!ect bits corresponding to the Ink fields, The ink 
field locations should have been determined before by using the method in 
Section '31.2.2.1 FieldVal= Decremented ink-remaining amount 


ResultFlag = Pass/Fail 


2 


A. Random 


None 


Ra=RL 


3 


B.Read 


KeyRef = n1 , SigOnly = 1 , (We only need the signature because we already 
know the data) MSelect = M0 , KeyldSelect = 0, WordSelectForDesiredM = 
corresponds to the ink fields written in Seq No 1 , RE= R A 


If ResultFlag = Pass then SelectedWordsOfSelectedMs not returned because 
[SigOnly] = 1 in Seq 3, R B = Rl, SIG b = SIGout Refer to Section 15.3.1. 


4 


A.Test 


KeyRef = n2, DataLength = length in words as per Seq No 1 [MVal] preformatted 
as per Section 16.1 , Data = as per Seq No 1 [MVal] preformatted as per Section 
16.1,RE=R B , SIGE = SIG B 


ResultFlag = Pass/Fail 



31 .4.3 Preauthorisation 

This section describes the update of logical ink amounts using preauthorisation. 
The basic preauthorisation sequence is as follows: 

a. Preauthorise before the first print. Preauthorisation amount depends on the printer model. 
Example amounts could be the ink required for an fully covered A4 page or an A3 page. 
Value corresponding to the preauth amount is written to the preauth field in the ink OA 
Device. 

Note: The preauth value must be correctly interpreted on different printer models Le If a 
preauthorisation amount ofA4 page is set in the ink cartridge in printer1(model1), and later the ink 
cartridge is placed in printer2(mode/2) with its preauth still set, printer! must deduct an A4 page 
worth of ink from ink-remaining amount 

b. Print the page. 

c. Write the deducted logical amount to the ink field of the ink OA Device and validate the write 
by reading the signature of the ink field. 

d. Repeat b to c till the last page has been printed. 

e. Clear the preauth amount. 
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f. If the power is cut off before the preauth is applied, on startup apply the preauth amount to 
the corresponding ink field, by performing a non authenticated write of the decremented 
amount and clear the preauth amount by performing an authenticated write of the preauth 
field. 

5 31.4.3.1 Set up of the preauth field 

Only a single preauth gield must exist in an Ink OA Device. 
Preauth field will consist of a single M o word but can be optionally extended to two M0 words by 
using a different value of type attribute. Figure 388 shows the setup of preauth field's attributes in 

M1- 

1 0 . The preauth field has authenticated ReadWrite access using the INK_USAGE_KEY i.e 

INK_USAGE_KEY can perform authenticated writes to this field. This key or its variant is shared 
between the ink OA Device and the printer OA Device to validate any data read from the ink 
cartridge. For signature to be valid, B.K n1 = A.K^ or B.K n i = FormKeyVariant(A.Kn2 , B.ChipId), 
where K n1 = INK_USAGE_KEY. The system performs a WriteAuth to the preauth field using this 
1 5 key, to set up the preauth amount, and to clear the preauth amount. 
The preauth field is identified by two attributes: 
o Type attribute - TYPE_PREAUTH . Refer to Appendix A. 
o Key Id of KeyNum attribute must be the same as the Key Id of the 

INK_USAGE_KEY which the printer uses to validate the any data read from the ink QA 
20 Device. 

The Preauth field can be applied to a single ink field or multiple ink fields. 
31.4.3.2 Preauth applied to a single ink field 

In this case the entire preauth field is used to store the preauth amount and is only linked to one ink 
field. 

25 31.4.3.3 Preauth applied to multiple ink fields 

Multiple preauth fields can be accommodated in a single M o field by a scheme shown in Figure 
388A. 

This scheme supports a maximum of 8 ink fields being present in the Ink QA Device. 

The field in M0 is divided into two parts- preauth field select and preauth amount. Each bit in preauth 

30 field select corresponds to a single ink field, and the preauth amount for each ink field is the same. 
If an ink cartridge uses multiple inks which are preauthorised, then each of the inks will have a 
corresponding preauth field bit. Before a particular ink is used for printing the corresponding preauth 
field bit is set. The preauth amount field is also set if the previous amount is zero. At finish, the 
preauth field bit is cleared. If more than one ink is used, the preauth bit for each ink field is set, and 

35 at finish each bit is cleared with last bit clearing the preauth amount as well. 
31.4.3.4 Locating preauth fields and determining preauth field value 
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The preauth field can be located in the same manner as the ink field. If the printer wants to find the 
preauth field in the ink OA Device, it must call the function FindFieldNum (see Section 31 .2.2.2) with 
keyidRequired = Keyld of Network_OEMJnk_Usage_Key and typeRequired = TYPE_PREAUTH. 
The preauth field value can be read in the same manner as the ink-remaining amount. This requires 
5 using of the function GetFieldDataWords(FieldNum,FieldData[], M0,M1) described in Section 
27.1 .4.14. FieldNum must be set to the value returned from function FindFieldNum, which in this 
case is the field number of the preauth field. FieldData returns the value of the preauth field. 
31.4.3.5 Command sequence 

The command sequence can be broken up into three parts: 
10 • Start of print sequence. 

• During print sequence. 

• End of print sequence. 

31 .4.3.5.1 Start of print sequence 
This sets up the preauth amount before the start of printing. 
1 5 Table 31 6 shows the command sequence for start of print sequence. The first Random- Read-Test 
sequence determines the preauth field in the ink OA Device and its value. The Random-SignM- 
WriteFieldsAuth sequence, then writes to the preauth field the new preauth value. 

Table 316. Updating the consumable remaining (preauth) start of print sequence 



Seq 
No 


Function 


Parameters 


Random-Read -Test sequence to determine the location of the preauth field in the ink QA Device and 
its value 


1 


A. Random 


None 






Ra = RL 


2 


B.Read 


KeyRef = n1 , SigOnly = 0, WordSelectForDesiredM (for M0 ) = all 16 words of 
MO and all 16 words of M1 MSelect = 0x03(indicates MO and M1), KeyldSelect 
= OxFF (Read all Keylds), WordSelectForDesiredM (for M0 )= OxFFFF (Read all 
16 M owords), WordSelectForDesiredM (for M1 )= OxFFFF(Read ail 16 M i words), 
RE= R A 






If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs as per 
input [MSelect] and [WordSelectForDesiredM], R B = Rl, SIG b = SIGout Refer 
to Section 15.3.1 


3 


A.Test 


KeyRef = n2, DataLength = length of MWords in words preformatted as per 
Section 16.1 , Data = MWords as per Seq No 2 preformatted as per Section 
16.1, RE =Rb, SIGE = SIG b 
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ResultFlag = Pass/Fail 








Random-SignM-WriteFieldsAuth sequence to write the new preauth value 


4 


B.Random 


None 


Rbi=RL 


5 


A.SignM 


KeyRef = n2, FieldSelect = Select bit corresponding to the Preauth field, 
FieldVal = new preauth value, Chipld = Chipld of B, R E = Rbi 


If ResultFlag = Pass then R Ar = R L SIG A = SIGout Refer to Section 27.1 .3.1 


6 


B.WriteFiefdsAuth 


KeyRef = n1, FieldSelect= same as Seq 5 [FieldSelect], FieldVai= same as 
Seq 5 [FieldVal], RE= R A1 , SIGE = SIG A 


ResultFlag = Pass /Fail 



31.4.3.5.2 

During print sequence 

5 This set of commands are repeated at equal intervals to update logical ink amounts to the ink QA 
Device during printing. 

Table 31 7 shows the command sequence for the print sequence. The WriteFields writes the 
updated value to the ink field. Random-Read-Test reads back the value written and tests whether 
the value read matches the value written. 
1 0 Table 31 7. Updating the consumable remaining (preauth) during print sequence 



Seq 
No 


Function 


Parameters 


Write the decremented ink-remaining account 


7 


S. WriteFields 


FieldSelect = Select bits corresponding to the Ink fields, 
FieldVal= Decremented ink-remaining amount for a single ink or 
multiple ink fields as per FieldSelect. 






ResultFlag = Pass /Fail 


Random-Read-Test sequence to read and verify the ink-remaining amount written 


8 


A. Random 


None 






Ra = RL 


9 


B.Read 


KeyRef = n1 , SigOnly = 1 -(We only need the signature because 
we already know the data), MSelect =0x01 (only M0 ), KeyldSelect 
= 0, WordSelectForDesiredM = corresponds to the ink fields 
written in Seq No 7, RE= R A 
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If ResultFlag = Pass then SelectedWordsOfSelectedMs not 
returned because [SigOnly] = 1 in Seq 9 Re = Rl, SIG b = SIGout 
Refer to Section 15.3.1. 


10 


A.Test 


KeyRef = n2, DataLength = length in words as per Seq No 7 
[MVal] preformatted as per Section 16.1, Data = as per Seq No 
7 [MVal] preformatted as per Section 16.1, RE =R B , SIGE = SIG B 


ResultFlag = Pass/Fail 



31 .4.3.5.3 End of print sequence 

This sequence clears preauth amount before the print sequence is completed. 
Table 318 shows the command sequence for the end of print sequence. 
5 The preauth field is read using the Random-Read-Test sequence. And the preauth field is cleared 
using the Random-SignM-WriteFieldsAuth sequence. 

Table 318. Updating the consumable remaining (preauth) end of print sequence 



Seq 
No 


Function 


Parameters 


Random-Read-Test sequence to read the preauth field and verify the preauth data 


11 


A.Random 


None 


Ra=Rl ' '' j 


12 


B.Read 


KeyRef = n1, SigOnly = 1, MSelect = 0x01 (only MO), KeyldSelect = 0, 
WordSelectForDesiredM (for M o)= Words corresponding to the Preauthfield 
that has been written to in Seq 5 [FieldSelect] in Table 317. RE= R A 


If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs as per 
Seq No 12 [MSelect] and [WordSelectForDesiredM], Rb = Rl, SIG B = SIGout 
Refer to Section 15.3.1 


13 


A.Test 


KeyRef = n2, DataLength = length of MWords in words as per Seq No 1 2 
preformatted as per Section 16.1, Data = MWords as per Seq No 12 
preformatted as per Section 16.1, RE =Rb, SIGE = SIG B 


ResultFlag = Pass/Fail j 


Random-SignM-WriteFieldsAuth sequence clears the preauth field 


14 


B. Random 


None 


Rbi = Rl 


15 


A.SignM 


KeyRef = n2, FieldSelect =Select bit corresponding to Pre authfield, FieldVal 
= Clear the preauth field, Chipld = Chipld of B, R E = Rbi 


If ResultFlag = Pass then Ra^ Rl SIG A =SIGout Refer to Section 27.1 .3.1 
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16 


B.WriteFieldsAuth 


KeyRef = n1, FieldNum = same as Seq 5 [FieldSelect], FieldData = same as 
Seq 5 [FieldVal], RE= Rbi, SIGE = SIG A 






ResultFlag = Pass /Fail 



31 .4.4 Preauthorlsation through the Translate function 

This is performed when the system trusted OA Device doesn't share a key with the ink OA Device, 
and uses a translating OA Device to Translate a Read from the ink OA Device, and to Translate a 
5 SignM to the ink OA Device. 

The basic translate principle involves translating the Read data from the untrusted QA Device, to 
the Test data of the trusted QA Device, and translating the SignM data from the trusted QA Device, 
to the WriteFieldsAuth data of the untrusted QA Device. 
For validating signatures using translation: 
10 • The trusted QA Device (A) and the translating QA Device (C) must share a common or a 
variant key i.e C.K^ = A.K^ or CK^ = FormKeyVariant(A.Kn2 , C.ChipId). 
• The ink QA Device (B) and the translating QA Device (C) must share a common or a variant 
keyi.e C.K^ = B.Km or B.Km = FormKeyVariantCC.K^, B.ChipId). 
Only the start of print sequence is described using Translate. The rest of the sequences in 
1 5 preauthorisation can be modified to apply translation using this example. 

Table 319 shows the command sequence for preauth (start of print sequence) using translation. 
Table 319. Preauth(start of print sequence) using translate command 



Seq 
No 


Function 


Parameter 


Random-Read-Random-Translate-Test sequence reads the location of the preauth field and its value 
using the translating QA Device C 


1 


C. Random 


None 






Rc= RL 


2 


B.Read 


KeyRef = n1 , SigOnly = 0, MSelect = 0x03(indicates MO and M1 ), KeyldSelect 
= OxFF (Read all Keylds), WordSelectForDesiredM (for M0 )= OxFFFF (Read all 
16 mo words), WordSelectForDesiredM (for M1 )= OxFFFF(Read all 16 M i words), 
RE=R A 






If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs as per 
input [MSelect] and [WordSelectForDesiredM], R B = R|_, SIG B = SIGout Refer 
to Section 15.3.1 


3 


A. Random 


None 






Ra= RL 
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4 


C. Translate 


InputKeyRef =n2, DataLength (in words) = length of MWords in words as per 
Seq No 2 preformatted as per Section n 17,1, Data = MWords as returned 
from Seq No 2 preformatted as per Section 1 7.1 , RE= Re, SIGE = SIG B 
OutputKeyRef = n3, RE2 = R A 


If ResultFlag = Pass then Rci= RL2, SIG C = SIGOut Refer to Figure 15.3.1 


5 


A.Test 


KeyRef = n2, DataLength = length of MWords in words as per Seq No 2 
preformatted as per Section 16.1, Data = MWords as returned from Seq No 2 
parameter preformatted as per Section 16.1 , RE =Rci, SIGE = SIG C 


ResultFlag = Pass/Fail 


Random-SignM-Random-Translate-WriteFieldAuth sequence to write the new preauth value using the translating 
QA Device C 


6 


C. Random 


None 


Rc2= Rl 


7 


A.SignM 


KeyRef = n2, FieldSelect =Select bit corresponding to Pre authfield, Field Val = 
new value of preauth field, Chipld = Chipld of B, R E = Rc 2 


If ResultFlag = Pass then R A i = RlSIG a = SIGout Refer to Section 27.1 .3.1 


8 


B. Random 


None 


Rbi = Rl 


9 


C. Translate 


InputKeyRef =n3, DataLength (in words) = length in words as per Seq 7 
[FieldSelect] preformatted as per Section 17.1, Data = same as Seq 7 
[FieldVal] preformatted as per Section 17.1, RE= R A1 , SIGE = SIG A , 
OutputKeyRef = n2, RE2 = R B i 


If ResultFlag = Pass then Rc3= Rl2, SIG c = SIGOut Refer to Figure 15.3.1 


10 


B.WriteFieldsAuth 


KeyRef = n1 , FieldNum = same as Seq 7 [FieldSelect], FieldData = same as 
Seq 7 [FieldVal], RE= Rc 3 , SIGE = SIG C 


ResultFlag = Pass /Fail, 



31 .5 Upgrading the printer parameters 

This sequence is performed when a printer's operating parameter is upgraded. 
The Parameter Upgrader QA Device stores the upgrade value which is copied to the operating 
5 parameter field of the Printer QA Device, and the count-remaining associated with upgrade value is 
decremented by 1 in the Parameter Upgrader QA Device. 

The Parameter Upgrader QA Device output the data and signature only after completing all 
necessary checks for the upgrade. 
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31.5.1 Basic 

The basic upgrade is used when the Parameter Upgrader QA Device and Printer OA Device being 
upgraded share a common key or a variant key i.e B.K^ = A.K^or B.Km = FormKeyVariantfA.K^ , 
B.ChipId), where B is the Printer QA Device and A is the Parameter Upgrader QA Device. 
5 Therefore, the messages and their signatures, generated by each of them can be correctly 
interpreted by the other. 

The transfer sequence is performed using Random-Read-Random-XferField-WriteFieldsAuth . 
Table 320 shows the command sequence for a basic upgrade. 

Table 320. Basic upgrade command sequence 

10 



Seq 
No 


Function 


Parameter 


Random-Read-Random-XferField-WriteFieldsAuth reads MO and Mlofthe QA Device being upgraded, 
Parameter Upgrader QA Device produces the upgrade value for FieldNumE and Sequence data ftelds 
SEQ_1 and SEQ_2, then these values are written to the Printer QA Device. 


1 


A. Random 


None 


Ra = Rl . - 


2 


B.Read 


KeyRef = n1, SigOnly = 0, MSelect = 3 (indicates M o and M i), KeyldSelect = 
0x00 (no Keylds required), WordSelectForDesiredM (for M0 )= OxFFFF (Read all 
Mowords), WordSelectForDesiredM (for M1 )= 0xFFFF(Read all M1 words), RE= 
Ra 


If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs, as per 
input [MSelect] and [WordSelectForDesiredM], R B = RL,. SIG B = SIGout Refer 
to Section 15.3.1 


3 


B. Random 


None j 


Rbi= Rl 


4 


A.XferField 


KeyRef = n2, M oOf External = First 16 words of MWords, M1 Of External Last 16 
words of MWords, Chipld = Chipld of B, FieldNumL= The field storing the 
upgrade value in the Parameter Upgrader QA Device. The value of this field 
will be copied to FieldNumE. FieldNumE= The field which will be upgraded in 
the Printer QA Device. Re= R b , Re2 = Rbi, SIG E = SIG b 


If ResultFlag = Pass then FieldSelectBI = FieldSelect - Select bits for 
FieldNumE and Seq data fields SEQ_1 and SEQ_2 field, FieldVaiBI = 
FieldVal -New Value for FieldNumE (Copied from FieldNumL of the Parameter 
Upgrader QA Device) and sequence data fields Rai= Ru , SIG A = SIGout = 
Refer to Section 27.1 .3.1 . 
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5 


B.WriteFieldsAuth 


KeyRef = n1, FieldSelect= FieldSelectBI, FieldData = FieldValBI, RE = R A1| 
SIGE = SIG A 






ResultFlag = Pass/Fail 



31 .5.2 Using the Translate function 

The upgrade through the Translate function is used when the Parameter Upgrader OA Device and 
the Printer OA Device don't share a key between them. The translating OA Device shares a key 
5 with the Parameter Upgrader OA Device and a second key with the Printer OA Device. Therefore 
the messages and their signatures, generated by the Parameter Upgrader QA Device and the 
Printer QA Device are translated appropriately by the translating QA Device. The translating QA 
Device validates the Read from the Printer QA Device, and translates it for input to the XferField 
function. The translating QA Device will validate the output from the XferField function, and then 
1 0 translate it for input to WriteFieldsAuth message of the Printer QA Device. 
For validating signatures using translation: 

• The Parameter Upgrader QA Device (A) and the translating QA Device (C) must share a 
common or a variant key i.e CK^ = A.K^ or CK^ = FormKeyVariant(A.Kn2 , C.ChipId). 

• The Printer QA Device (B) and the translating QA Device (C) must share a common or a 
1 5 variant key i.e C.Kn2 = B.K n i or B.K n1 = FormKeyVariant(C.Kn 2 , B.ChipId). 

Table 321 shows the command sequence for a basic refill using translation. 
Table 321 . An upgrade with translate command sequence 



Seq 
No 


Function 


Command 


Random-Read-Random- Translate-Random-XferField-Random- Translate-Random- WriteFieldsAuth 
reads MO and Mlofthe Printer QA Device using the translating QA Device C and then does a write of 
the upgrade value to FieldNumE and new sequence data to the seq data fields SEQ_1 and SEQ_2 field 
of the Printer QA Device using the translating QA Device C. 


1 


C. Random 


None 






Rc = Rl 


2 


B.Read 


KeyRef = nl, SigOnly = 0, MSelect =0x03(indicates M o and M i), KeyldSelect = 0x00 
(no Keylds required), WordSelectForDesiredM (for M0 )= OxFFFF (Read all MO words), 
WordSelectForDesiredM (for M i)= OxFFFF(Read all M i words), Re= Rc 






If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs as per input 
[MSelect] and [WordSelectForDesiredM], R B = RL, SIG B = SIGout Refer to 
Section 15.3.1 


3 


A. Random 


None 
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Ra= R|_ 


4 


C. Translate 


InputKeyRef =n2, DataLength = MWords length in words as per Seq No 2 
Preformatted as per Section 17.1, Data = MWords as returned from Seq No 2 
Preformatted as per Section 17.1, RE= R B , SIGE= SIG B , OutputKeyRef = n3, 
RE2 = R A 


If ResultFlag = Pass then Rc, = RL2, SIG C = SIGOut Refer to Section 1 7.3.1 


5 


C. Random 


None 


Rc2 = Rl 


6 


A.XferField 


KeyRef = n2, M0 OfExternal = First 16 words of MWords, M iOfExternal= Last 16 
words of MWords, Chipld = Chipld of B, FieldNumL= The field storing the 
upgrade value in the Parameter Upgrader OA Device. FieldNumE= The field 
which will be upgraded in the Printer OA Device. Re= Rci, Re2 = Rc2, SIG e = SIG c 


If ResultFlag = Pass then FieldSelectBI = FieldSelect - Select bits for FieldNumE 
and sequence fields, FieldValBI = FieldVal -New Value for FieldNumE (Copied 
from FieldNumL of the Parameter Upgrader QA Device) and sequence fields 
SECT 1 and SEQ_2, Rat= Rl2 , SIG A = SIGout Refer to Section 27.1 .3.1 


7 


B. Random 


None 


Rbi = Rl \l' ; 


8 


C. Translate 


InputKeyRef =n3, DataLength = FieldValBI length in words as per Seq No 6 
Preformatted as per Section 17.1, Data = FieldValBI as returned from Seq No 6 
Preformatted as per Section 17.1, RE= R A i, SIGE = SIG A , OutputKeyRef= n2, 
RE2 = Rbi 


If ResultFlag = Pass then Rc3 = Ri_2, SIGc 32 SIGOut Refer to Section 1 7.3.1 


19 
10 


B.WriteFieldsA 
uth 


KeyRef = n1, FieldSelect = FieldSelectBI, FieldVal = FieldValBI, RE = Rc 3> 
SIGE = SIGc 


ResultFlag = Pass/Fail , 



31 .6 Recovering from a failed upgrade 

This sequence is performed if the upgrade failed (for e.g Printer QA Device didn't receive the 
upgrade message correctly and hence didn't upgrade successfully). The Parameter Upgrader QA 
5 Device therefore needs to be rolled back to the previous value before the upgrade. In this case, the 
count-remaining associated with the upgrade value in the Parameter Upgrader QA Device is 
increased by one. 

The Parameter Upgrader QA Device checks that the Printer QA Device didn't actually receive the 
message correctly using the StartRollBack function. The RollBackFiefd performs further 
1 0 comparisons on sequence fields and FieldNumE of the Printer QA Device to values stored in the 
XferEntry cache. After performing all checks, the Parameter Upgrader QA Device increments the 
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count remaining field associated with the upgrade value field by one. Refer to Section 26 and 
Section 28 for details. 

The rollback is started using the Random-Read-Random-StartRollBack-WriteFieldsAuth and the 
rollback of the Parameter Upgrader OA Device is performed using Random-Read-RollBackField 
5 sequence. 

Table 322 shows the command sequence for a rollback upgrade. 



Seq 
No 


Function 


Command 


Random-Read-Random-StartRollBack-WriteFieldsAuth starts the rollback and updates data for the 
sequence fields. 


1 


A. Random 


None 






Ra = RL 


2 


B.Read 


KeyRef = nl, SigOnly = 0, MSelect =0x03(indicates M0 and M1 ), KeyldSelect = 0x00 
(no Keylds required), WordSelectForDesiredM (for M0 )= OxFFFF (Read all M o words), 
WordSelectForDesiredM (for M! )= OxFFFF(Read all M ,words), R E = R A 






If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs as per input 
[MSelect] and [WordSelectForDesiredM], Re = Ro SIG B = SIGout Refer to 
Section 15.3.1 


3 


B. Random 


None 






RB1 = Rl . :; ;V ;: -. \.VJ:::: : -.' . 


4 


A.StartRoll 
Back 


KeyRef = n2, M oOf External = First 16 words of MWords, M1 Of External Last 16 
words of MWords, Chipld = Chipld of B, FieldNumE= The field which was not 
upgraded in the Printer QA Device, FieldNumL = The upgrade value in the 
Parameter Upgrader QA Device which couldn't be copied to FieldNumE of the 
Printer QA Device, R E = Rb, Re2 = Rbl SIG e = SIG b 






If ResultFlag = Pass then FieldSelectB = FieldSelect - Select bits for sequence 
data fields SEQ_1 and SEQ_2, FieidValB = Field Va! - New values for SEQ_1 
and SEEQ_2 fields R A1 = R^SIGa = SIGout Refer to Section 27.1.3.1. 


5 


B.WriteFiel 
dsAuth 


KeyRef = n1, FieldSelect= FieldSelectB, FieldData = FieidValB, RE = R A1 , SIGE 
= SIG A 






ResultFlag = Pass/Fail 


Random-Read-RollBackField performs a read of the QA Device being upgraded, checks its values are as 
perXfer Entry cache, and then adjusts its count-remaining field. 


6 


A. Random 


None 






Ra2 = RL 
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7 


S. Read 


KeyRef = nl , SigOnly = 0, MSelect =0x03(indicates M o and M i), KeyldSelect = 0x00 
(no Keylds required), WordSelectForDesiredM (for M0 )= OxFFFF (Read all M owords), 
WordSelectForDesiredM (for M i)= OxFFFF(Read all M iwords), Re= 


If ResultFlag = Pass then M Words = Selected WordsOf Selected Ms as per input 
[MSelect] and [WordSelectForDesiredM], R B2 = RL, SIG B = SIGout Refer to 
Section 15.3.1 


8 


A. Roll Back 
Field 


KeyRef = n2, M0 Of External = First 16 words of MWords, M iOfExternal= Last 16 
words of MWords, Chipld = Chipld of B, FieldNumE= The field which was not 
upgraded in the Printer OA Device, FieldNumL = The upgrade value in the 
Parameter Upgrader OA Device which couldn't be copied to FieldNumE of the 
Printer OA Device, R E = Rb2, SIG e = SIG B 


ResultFlag = Pass/Fail 



31 .7 Re/filling the consumable (ink) 

This sequence is performed when an ink cartridge is first manufactured or after all the physical ink 
has been used, it can be filled or refilled. The re/fill protocol is used to transfer the logical ink from 
5 the Ink Refill OA Device to the Ink OA Device in the ink cartridge. 

The Ink Refill QA Device stores the amount of logical ink corresponding to the physical ink in the 
refill station. During the refill, the required logical amount (corresponding to the physical transfer 
amount) is transferred from the Ink Refill QA Device to the Ink QA Device. 
The Ink Refill QA Device output the transfer data only after completing all necessary checks to 
1 0 ensure that correct logical ink type is being transferred e.g Network_OEM1_infrared ink is not 
transferred to Network_OEM2_cyan ink. Refer to the XferAmount command in Section 27.1 . 
31.7.1 Basic refill 

The basic refill is used when the Ink Refill QA Device and the Ink QA Device share a common key 
or a variant key i.e B.K n1 = A.K^or B.Km = FormKeyVariantfA.K^ , B.ChipId) where B is the Ink QA 
1 5 Device and A is the Ink Refill QA Device. Therefore, the messages and their signatures, generated 
by each of them can be correctly interpreted by the other. 

The Xfer Sequence is started using Random-Read-Random-StartXfer-WriteAuth and the the Xfer 
Amount is written to the QA Device being refilled using Random-Read-Random-XferAmount- 
WriteFie/dsAuth sequence. 
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Table 323 - the command sequence for a basic refill. 



Seq 
No 


Function 


Parameter 


Random-Read-Random-XferAmount-WriteFieldsAuth reads MO and M1 of the Ink QA Device being 
refilled, produce updated amount for FieldNumE and sequence datat field by calling XferAmount on Ink 
Refill QA Device, and finally writing the updated value to Ink QA Device using WriteFieldsAuth. 


1 


A.Random 


None 


R A = Rl 


2 


B. Read 


KeyRef = n1 , SigOnly = 0, MSelect = 0x03(indicates M o and M1 ), KeyldSelect = 
0x00 (no Keylds required), WordSelectForDesiredM (for M0 )= OxFFFF (Read all 
M owords), WordSelectForDesiredM (for M i)= OxFFFF(Read all M1 words), RE= R A 


If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs as per input 
[MSelect] and [WordSelectForDesiredM], R B = RL, SIG B = SIGout Refer to 
Section 15.3.1 


3 


B. Random 


None 


RB1 = Rl :\V" . • •• 


4 


AxferAmount 


KeyRef = n2, M0 Of External = First 16 words of MWords, M tOfExternal= Last 16 
words of MWords, Chipld = Chipld of B, FieldNumL= ink-remaining field of the 
Ink Refill QA Device, FieldNumE= ink-remaining field of the Ink QA Device, 
XferValLength = length in words of XferVal XferVal = Value to be transferred 
from Ink Refill QA Device to Ink QA Device being refilled, R E= R B , Re2= Rbl 
SIG E = SIG B 






If ResultFlag = Pass then FieldSelectBI = FieldSelect - Select bits for FieldNumE 
and sequence data field SEQ_1 and SEQ_2, FieldValBI = FieldVal -New Value 
for FieldNumE (transferred from FieldNumL of the Ink Refill QA Device) and 
sequence data fields SEQ_1 and SEQ_2, R A i = Ri_2, SIG A = SIGout Refer to 
Section 27.1.3.1. 


5 


B.WriteFieldsAut 
h 


KeyRef = n1, FieldSelect= FieldSelectB, FieldData = FieldValB, RE = R A i. SIGE 
= SIG A 


ResultFlag = Pass/Fail 



5 31 .7.2 Using the Translate function 

The refill through the Translate function is used when the Ink Refill QA Device and the Ink QA 
Device don't share a key between them. The translating QA Device shares a key with the Ink Refill 
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QA Device and a second key with the Ink QA Device. Therefore the messages and their signatures, 
generated by the Ink Refill QA Device and the Ink QA Device, are translated appropriately by the 
translating QA Device. The translating QA Device validates the Read from the Ink QA Device, and 
translates it for input to the XferAmount function. The translating QA Device will validate the output 
5 from the XferAmount function, and then translate it for input to WriteFieldsAuth message of the Ink 
QA Device. 

For validating signatures using translation: 

• The Ink Refill QA Device (A) and the translating QA Device (C) must share a common or a 
variant key i.e CK^ = A.K^ or CK^ = FormKeyVariantfA.K,* , C.ChipId). 
10 • The Ink Refill QA Device being refilled (B) and the translating QA Device (C) must share a 
common or a variant key i.e C.K^ = B.Km or B.Kni = FormKeyVariantfC.K^, B.ChipId). 
Table 324. A basic refill using translation command sequence 



Seq 
No 


Function 


Command 


\Random-Read-Random- Trans/ate-Random-XferAmount-Random- Translate-Random-WriteFieldsAuth - 
Veads MO and M1 of the Ink QA Device being refiffed using the translating QA Device C , produce 
{updated amount for FieldNumE and sequence data field by calling XferAmount on Ink Refill QA Device, 
land finally writing the updated value to Ink QA Device using the translating QA Device. 


1 C. Random 


None 


Rc = Rl 


2 


B.Read 


KeyRef = nl, SigOnly = 0, MSelect =0x03(indicates M0 and M i), KeyldSelect = 0x00 
(no Keylds required), WordSelectForDesiredM (for M0 )= OxFFFF (Read all M owords), 
WordSelectForDesiredM (for M1 )= 0xFFFF(Read all MI words), Re= Rc 


If ResultFlag = Pass then MWords = SeiectedWordsOfSelectedMs as per input 
[MSelect] and [WordSelectForDesiredM], Re = Rl, SIG b = SIGout Refer to 
Section 15.3.1 


3 


A. Random 


None 


Ra = Rl 


4 


C. Translate 


InputKeyRef =n2, DataLength = MWords length in words as per Seq No 2 
Preformatted as per Section 1 7.1 , Data = MWords as returned from Seq No 2 
Preformatted as per Section 17.1, RE= Re, SIGE= SIG B , OutputKeyRef = n3, 
RE2 = R A 


If ResultFlag = Pass then Rci= Rl2,SIG c = SIGOut Refer to Section 17.3.1 


5 


C. Random 


None 


Rl= Rc2 
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6 


A.XferAmount 


KeyRef = n2, M0 OfExternal = First 16 words of MWords, M1 OfExternal= Last 16 
words of MWords, Chipld = Chipld of B, FieldNumL= ink-remaining field of the 
Ink Refill OA Device, FieldNumE= ink-remaining field of the Ink OA Device, 
XferValLength = length in words of XferVal XferVal = Value to be transferred 
from Ink Refill QA Device to Ink QA Device being refilled, R E = Rci, Re2 = Rc2, 
SIG E = SIG C 


If ResultFlag = Pass then FieldSelectBI = FieldSelect - Select bits for FieldNumE 
and sequence data field SEQ_1 and SEQ_2, FieldValBI = FieldVal -New Value 
for FieldNumE (transferred from FieldNumL of the Ink Refill QA Device) and 
sequence data fields SEQ_1 and SEQ_2, R A i= Rl2 , SIG A = SIGout Refer to 
Section 27.1.3.1 


7 


B. Random 


None 


Rbi = Rl 


8 


C. Translate 


InputKeyRef =n3, DataLength = FieldValB length in words as per Seq No 6 
Preformatted as per Section 17.1, Data = FieldValB as returned from Seq No 6 
Preformatted as per Section 17.1, RE= R A i, SIGE = SIG A , OutputKeyRef= n2, 
RE2 = Rbi 


If ResultFlag = Pass then Ro = RL2, SIG C = SIGOut Refer to Section 1 7.3.1 


9 


B.WriteFieldsAuth 


KeyRef = n1, FieldSelect= FieldSelectB, FieldData = FieldValB, RE = Rc 3 , SIGE 
= SIG C 


ResultFlag - Pass/Fail 



31 .8 Recovering from a failed refill 

This sequence is performed if the refill failed (for e.g Ink QA Device didn't receive the refill message 
correctly and hence didn't refill successfully). The Ink Refill QA Device therefore needs to be rolled 
5 back to the previous value before the refill. 

The Ink Refill QA Device checks that the Ink QA Device didn't actually receive the message 
correctly using the StartRolIBack function. The RollBackAmount performs further comparisons on 
sequence data field and FieldNumE of the Ink QA Device, to values stored in the XferEntry cache. 
After performing all checks, the Ink Refill QA Device adjusts its ink field to a previous value before 
1 0 the transfer request was processed by it. Refer to Section 26 and Section 28 for details. 

The rollback is started using the Random-Read-Random-StartRollBack-WriteFieldsAuth and the 
rollback of the Ink Refill QA Device is performed using Random-Read-RollBackAmount sequence. 
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Table 325. Rollback amount command sequence 



SeqlFunction 
No 


Command 


Random-Read-Random-StartRollBack-WriteAuth starts the rollback and updates data for the sequence 
data fields SEQ_1 and SEQ_2 . 


1 


A.Random 


None 






Ra = RL 


2 


B.Read 


KeyRef = nl, SigOnly = 0, MSelect =0x03(indicates M o and M1 ), KeyldSelect = 0x00 
(no Keylds required), WordSelectForDesiredM (for M0 )= OxFFFF (Read all M owords), 
WordSelectForDesiredM (for M1 )= 0xFFFF(Read all M iwords), R E = R A 






If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs as per input 
[MSelect] and [WordSelectForDesiredM], Rb = RL, SIG b = SIGout Refer to 
Section 15.3.1 ■ . , 


3 


B. Random 


None 






Rbi = Rl «' • ' -"*• 


4 


A.StartRollBack 


KeyRef = n2, M oOf External = First 16 words of MWords, M iOf External Last 16 
words of MWords, Chipld = Chipld of B, FieldNumL= ink-remaining field of the 
Ink Refill QA Device which will be adjusted to the value before the failed refill, 
FieldNumE= ink-remaining field of the Ink QA Device which failed to refill, Re= 
Rb, Re2 = Rbi SIG e = SIG b 






If ResultFlag = Pass then FieldSelectB = FieldSelect - Select bits for sequence 
data fields- SEQ_1 and SEQ_2, FieldValB = FieldVal - New value for sequence 
data fields SEQ_1 and SEQ__2 R A1 = R^, SIG A = SIGout Refer to Section 
27.1.31. r > : '; : ? J >"^^;;;;r' J ' ^l '-^'- 1 


5 


B.WriteFieldsAuth 


KeyRef = n1 , FieldSelect= FieldSelectB in Seq No 4, FieldData = FieldValB in 
Seq No 4 RE = R A1 , SIGE = SIG A 


10 




ResultFlag = Pass/Fail 


Random-Read-RollBackAmount performs a read of the Ink QA Device, checks its values are as perXfer 
Entry cache, and then adjusts its ink-remaining field. 


11 


A.Random 


None 






Ra2. = RL 


12 


B.Read 


KeyRef = nl, SigOnly = 0, MSelect =0x03(indicates M o and M1 ), KeyldReq = 0 (not 
required), KeyldSelect = 0x00 (no Keylds required), WordSelectForDesiredM (for 
M0 )= OxFFFF (Read all M owords), WordSelectForDesiredM (for M i)= 0xFFFF(Read all 
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M1 words), RE= Ra2 


If ResultFlag = Pass then MWords = SelectedWordsOfSelectedMs as per input 
MSelect] and [WordSelectForDesiredM], Re 2 = Rl, SIG b = SIGout Refer to 
Section 15.3.1 


13 


A.RollBackAmount 


KeyRef = n2, M oOfExternal = First 16 words of MWords, M iOfExternal= Last 16 
words of MWords, Chipld = Chipld of B, FieldNumL= ink-remaining field of Ink 
Refill QA Device which will be adjusted to the value before the failed refill, 
FieldNumE= ink-remaining field of Ink QA Device which failed to refill, R E = R B 2, 
SIG E = SIG b 


ResultFlag = Pass/Fail 



31 .9 Upgrading/Refilling/filling the upgrader 

This sequence is performed when a count-remaining field in the Parameter QA Device must be 
updated or when the ink-remaining field in the Ink Refill QA Device requires re/filling. 
5 In case of the Parameter QA Device, another Parameter Upgrader Refill QA Device transfers its 
count-remaining value to the Parameter QA Device using the transfer sequence described in 
Section 31 .4. Also refer to Section 28.6. This means the count-remaining in the Paramater 
Upgrader Refill QA Device must be decremented by the same amount that Parameter Upgrader QA 
Device is incremented by i.e a credit transfer occurs. 

10 In case of the Ink Refill QA Device, another Ink Refill QA Device transfers its ink-remaining value to 
the Ink Refill QA Device using the transfer sequence described in Section 31 .4. Also refer to 
Section 26.4. This means the logical ink-remaining in the Ink Refill QA Device must be decremented 
by the same amount that QA Device being refilled is incremented by i.e a credit transfer occurs. 
32 Setting up for field use 

1 5 This section consists of setting up the data structures in the QA Device correctly for field use. All 
data structures are first programmed to factory values. Some of the data structures can then be 
changed to application specific values at the ComCo or the OEM, while others are set to fixed 
values. 

32.1 Instantiating the QA Chip Logical Interface 
20 This sequence is performed when the QA Device is first created. Table 326 shows the data 
structure on final program load. 
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Table 326. Data structure set up during final program load 



Data Structure 
Name 


value Set to 


Fixed or Updatable 


umpia 


Unique Identifier for QA Device 


Fixed 


NumKey 


Number of keys the QA Device can hold 


Fixed 


is 


All Kn - Kbatch- The K ba t C h is unique for a 
production oaten . 


Updateable if previous value is 
known 


r\eyia 


f\\\ Keyias - f\eyia ot r\batch- 


Updateable along with K n . 


YC&\A nrk 
r\cy l_ rv 




upuaieauie 


NumVectors 


Number of memory vectors in the QA Device. 


Fixed 


MO 


Set to zeros 


Updateable 


MO 


Set to zeros 


Updateable 


M 2 + 


Set to zeros 


Updateable 


Pn 


Set to ones 


Updateable 


R 


Set to an initial random value 


Updateable 



Each key slot has the same K batch . If each key slot had a different K^ch , and any one of the Kbatch 
5 was compromised then the entire batch would be compromised till the Kbatch was replaced to 

another key. Hence, each key slot having a different K bat ch doesn't have any security advantages 

but requires more keys to be managed. 

32.2 Setting up application specific data 

The section defines the sequences for configuring the data structures in the QA Device to 
1 0 application specific data. 
32.2.1 Replacing keys 

The QA Devices are programmed with production batch keys at final program load. The COMCO 
keys replace the production batch keys before the QA Devices are shipped to the ComCo. The 
ComCo replaces the COMCO keys to COMCOJDEM when shipping QA Devices to its OEMs. 
1 5 The OEM replaces the COMCO_OEM to COMCOjOEM_app as the QA Devices are placed in ink 
cartridges or printers. 

The replacement occurs without the ComCo or the OEM knowing the actual value of the key. The 
actual value of the keys is only to known to QACo. The ComCo or the OEM is able to perform these 
replacements because the QACo provides them with a key programming QA Device with keys 
20 appropriately set which can generate the necessary messages and signatures to replace the old 
key with the new key. 

Table 327 shows the command sequence for ReplaceKey. The GetProgramKey gets the new 
encrypted key from the key programming QA Device, and the encrypted new key is passed into the 



909 



QA Device whose key is being replaced through the RepfaceKey function. Depending on the 
OldKeyRef and NewKeyRef objects a common encrypted key or a variant encrypted key can be 
produced for the ReplaceKey function 



Table 327. ReplaceKey command sequence 

5 



Seq 
No 


Function 


Command 


1 


B. Random 


None 






Rb = Rl 


2 


A.GetProgramKe 

y 


OldKeyRef = Key Num of the old key. This key must be changed to the 
NewKeyRef in the QA Device whose key s being replaced. Chipld = Chip 
identifier of the QA Device whose key is being replaced. RE= R B KeyLock = Set 
depending on whether the new key is the final key for the key slot or it will be 
replaced further. NewKeyRef = Key Num of the new key. This key will change 
the OldKeyRef in the QA Device whose key is being replaced. 






If ResultFlag = Pass then R A = RL, Keyld new = KeyldOfNewKey EncryptedNewKey 
= EncryptedKey , SIGA = SIGout Refer to Section 22.2.1 . 


3 


B.ReplaceKey 


KeyNumToBeReplaced = Old key number, the old key could be a common key 
or a variant key, Keyld = Keyldnew, EncryptedKey= EncryptedNewKey, RE = RA, 
SIGE = SIGA 






ResultFlag = Pass/Fail 



32.2.2 Setting up Readonly data 

This sets the permanent functional parameters of the application where the QA Device has been 
placed. These parameters remain unchanged for the lifetime of the QA Device. In case of the ink 
1 0 cartridge such parameters are colour and viscosity of the ink. These values are written to M 2+ 

memory vectors using the WriteM1+ function, and its permissions are set to Readonly by SetPerm 

function. These values are typically set at the OEM. 

Table 328 shows the command sequence for setting up Readonly data. 

Table 328. Readonly data setup command sequence 

15 



Seq 
No 


Function 


Command 


1 


B.WriteM1+ 


VectNum = 2 or 3, WordSelect = the selected words to be 
written, MVal = words corresponding to word select starting 
from LSW 
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ResuftFlag = Pass/Fail 


2 


B.SetPerm 


(VectNum =same as Seq No 1 parameter [VectNum], PermVal 
=same as Seq No 1 parameter [WordSelecty 


If ResuftFlag = Pass then CurrPerm = NewPerm Current 
permission value after applying PermVal 



In case of the SBR4320, the values written to M 2+ memory vectors is write-once only Le they are set 
to Readonly as soon as they are written to once, therefore the command sequence consists only of 
Seq No 1 in Table 329. 
5 32.2.3 Defining fields in M0 

The QACo must determine the field definitions for MO depending on the application of the QA 
Device. These field definitions will consist of the following: 

• Number of fields and the size of each field. 

• The Type attribute of each field. 

10 • The access permission for each field. 

Following fields have been presently defined in an ink QA Device: 

• ink-remaining field. See Section 26 for details. 

• Preauthorisation field. See Section 31 .4.3 for details. 

• Sequence data fields SEQ_1 and SEQJ2. See Section 26 for details. 
1 5 Following fields have been presently defined in a printer QA Device: 

• Operating parameter field.See Section 28 for details. 

• Sequence data fields SEQ_1 and SEQ_2. See Section 26 for details. 

After the field definitions are determined, they are formatted as per Section 8.1 .1 .4. These formatted 
values are then written to M i using a WriteM1+ function. 
20 Table 329. Defining MO fields command sequence 



Sequence 
No 


Function 


Command 


1 


B.WriteM1+ 


VectNum = 1, Wore/Select = The selected words corresponding to 
the attribute field/fields of M o, MVal = words corresponding to word 
select starting from LS\N) 


ResuftFlag = Pass/Fail 



32.2.4 Writing values to fields in M0 
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The writing of M o fields for an Ink OA Device will typically occur when the ink cartridge is filled with 
physical ink for the first time, and the equivalent logical ink is written to the Ink OA Device. Refer to 
Section 31 .7 for details. 

The writing of M o fields for a Printer OA Device will typically occur when the printer parameters are 
5 written for the first time. The procedure for writing of a printer parameter for the first time or 
upgrading a printer parameters is exactly the same. Refer to Section 31 .5 for details. 
Before any value is written to a field, the key slot containing the key which has authenticated 
ReadWrite access to the field must be locked. 

Both Ink OA Device and Printer QA Device has a sequence data fields SEQ_1 and SEQ_2 as 
1 0 described in Section 27. These two fields must be initialised to OxFFFFFFFF, refer to Section 27 for 
details. 

The Ink QA Device/Printer QA Device and the trusted QA Device writing to it, share the sequence 
key or a variant sequence key between them i.e B.K n i = A.K^or B.K n1 = FormKeyVariant(A.Kn2, 
B.ChipId), where B is the Ink QA Device/Printer QA Device and A is the trusted QA Device. The 
1 5 command sequence used is described in Table 330. 

Table 330. Command sequence for writing sequence data fields to the QA Devices. 



Sequence 
No 


Function 


Parameters 


1 


B. Random 




Rb = /?l •:, : ,T. :: -V>. 


2 


A.SignM 


KeyRef = n2, FieldSelect =Select bit correponding to SEQ_1 
and SEQ-2 FieldVal = both fields set OxFFFFFFFF. Refer to 
Section 31 .4.3.3 Chipld = Chipld of B, R E = R B 


If ResultFlag = Pass then Ra= Rl SIG A =SIGout Refer to 
Section 27.1.3.1 


3 


B.WriteFieldsAuth 


KeyRef = n1 , FieldSelect = same as Seq 2[FieldSelect], 
FieldVal = same as Seq 2[FieldVal], RE= R A , SIGE = SIG A 


ResultFlag = Pass /Fail 



32.3 Setting up the upgrading QA Device 
20 The upgrading QA Device must be set up either as an Ink Refill QA Device or as a Parameter 
Upgrader QA Device. 

Each upgrading QA Device must go through the following set up: 

o The upgrading QA Device must be set to factory defaults. Refer to Section 32.1 . At the end of 
this process the upgrading QA Device is either an Ink Refill QA Device or a Parameter 
25 Upgrader QA Device with production batch keys and MO fields set to deafult. 
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© The upgrading OA Device must be programmed with the appropriate keys and upgrade data 
before it can start upgrading other OA Devices. Following must be performed on each 
upgrade OA Device: 

a. The upgrading OA Device must be programmed with the appropriate keys required to upgrade 
5 other QA Devices and to upgrade itself when necessary. 

b. The MO fields must be correctly defined and set in M1 . 

For a Ink Refill QA Device the ink-remaining field must be defined and set. For a printer upgrade 
QA Device the upgrade value field and the count-remaining field must be defined and set. 
All upgrade QA Devices must also have a sequence datat fields SEQ_1 and SEQ_2 which are 
1 0 used to upgrade the upgrading QA Device itself. 

c. Finally, MO fields defined in b must be written with appropriate values so that the upgrade QA 
Device can perform upgrades. 

An Ink Refill QA Device will typically store the logical ink equivalent to the physical ink in a refill 
station, hence the Ink Refill QA Device's ink-remaining field must be written with the equivalent 
1 5 logical ink amount. 

For a Parameter Upgrader QA Device the upgrade value field and the count-remaining field must 
be written. The upgrade value depends on the type of upgrade the Parameter Upgrader QA 
Device can perform i.e one Parameter Upgrader QA Device can upgrade to 10 ppm (pages per 
minute) while another Parameter Upgrader QA Device can upgrade to 5ppm. The count- 
20 remaining is the number of times the Parameter Upgrader QA Device is permitted to write the 

associated upgrade value to other QA Devices. The count-remaining field must be written to a 
positive non-zero value for the Parameter Upgrader QA Device to perform successful upgrades. 
Refer to Section 32.3.1 and Section 32.3.2 for details. 
32.3.1 Setting up the Ink Refill QA Device 
25 32.3.1.1 Setting up the keys 

The Ink Refill QA DeviceQA Device could be transferring ink between peers or transferring ink down 
the heirachy, accordingly the peer to peer Ink Refill QA Device has two keys (fili/refil/ key and 
sequence key ) as described in Section 27, and a Ink Refill QA Device transferring down the 
heirachy has three keys (fill/refill key, transfer key and sequence key). These keys must be 
30 programmed into the Ink Refill QA Device using the sequence described in Section 32.2.1 . 

The Key Programming QA Device must be programmed with the appropriate production batch keys 
, and the fill/refill, transfer key and sequence key 

The GetProgramKey function is called on the Key Programming QA Device with OldKeyRef 
(OldKeyRef - refer to Section 32.2.1) pointing to a production batch key, and the NewKeyRef 
35 (NewKeyRef - refer to Section 32.2.1 ) pointing to either a fill/refill key or a transfer key or a 

sequence key. The outputs from the GetProgramKey (signature and encrypted New Key) is passed 
in to ReplaceKey function of the Ink Refill QA Device. 
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The GetProgramKey function must be called (on the Key Programming QA Device) for replacing 
each of the production batch keys in the Ink Refill QA Device. The output of the GetProgramKey will 
be passed in to the ReplaceKey function called on the Ink Refill QA Device. The successful 
processing of the ReplaceKey function will replace an old key(production keys ) to a corresponding 
5 new key ( either a fill/refill key or a transfer key or a sequence key). 

32.3. 1.2 Setting up the MO field information in M1 

The ink-remaining field and the sequence data fields SEQ_1 and SEQ_2 must be defined and set in 
the Ink Refill QA Device using the sequence described in Section 32.2.3. 

32. 3.1.3 Transferring ink amounts 

1 0 Finally, the logical ink amounts are transferred to the ink-remaining field using the sequence 
described in Section 31.7. 

The QACo will transfer to the ComCo Ink Refill QA Device at the top of the heirachy using the 
command sequence in Table 331 . 

For a successful transfer from QACo to ComCo, ComCo and QACo must share a common key or a 
1 5 variant key be i.e ComCo.K n1 = QACo.K^ or ComCo.K n i = FormKeyVariant(QACo.Kn2 
,ComCo.Chipld)K n i is the fill/refill key for the ComCo refill QA Device.. 

Table 331 . Command sequence for writing ink-remaining amounts to the highest 

QA Device in the heirachy. 



Sequence 
No 


Function 


Parameters 


1 


B. Random 




Re = RL y,;-: • ;•••;•/ ; , .: ■ S;V \ . V ■ 


2 


A.SignM 


KeyRef = n2, FieldSelect =Select bit correponding to the ink- 
remaining field, FieldVal = Ink amount to be transferred, Refer 
to Section 31 .4.3.3 Chipld = Chipld of B, Re= Rb 


If ResultFlag = Pass then R A = Rl SIG a =SIGout Refer to 
Section 27.1:3.1 ^ 


3 


B.WriteFieldsAuth 


KeyRef = n1 , FieldSelect = same as Seq 2[FieldSelect], 
FieldVal = same as Seq 2[FieldVal], RE= R A , SIGE = SIG A 


ResultFlag = Pass /Fail 



20 ~ ~ ~ ~ = ^ " " "~ 

32.3. 1.4 Setting up sequence data fields 

The Ink Refill QA Device has sequence data fields SEQ_1 and SEQ_2 (as described in Section 27) 
because its ink-remaining fields can be refilled as well. These two fields must be initialised to 
OxFFFFFFFF, refer to Section 27 for details. 
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The Ink Refill OA Device and the trusted QA Device writing to it, share the sequence key or a 
variant sequence key between them i.e B.Km = A.K^or B.Km = FormKeyVariantfA.K^, B.ChipId), 
where B is the Ink Refill QA Device and A is the trusted QA Device. The command sequence used 
is described in Table 331 . 
5 32.3.2 Setting up the Parameter Upgrader QA Device 

32.3.2.1 Setting up the keys 

The Parameter Upgrader QA Device could be transferring upgrades between peers or transferring 
upgrades down the heirachy, accordingly the peer to peer Parameter Upgrader QA Device has 
three keys (write-parameter key, fill/refill key and sequence key) as described in Section 28.6 and 
1 0 Section 26, and a Parameter Upgrader QA Device transferring down the heirachy has four keys 
(write-parameter key, fill/refill key, transfer key and sequence Key). These keys must be 
programmed into the Parameter Upgrader QA Device using the sequence described in Section 
32.2.1. 

The Key Programming QA Device must be programmed with the appropriate production batch keys 

1 5 , and write-parameter key, fill/refill key, transfer key and sequence key 

The GetProgramKey function is called on the Key Programming QA Device with OldKeyRef 
(OldKeyRef - refer to Section 32.2.1 ) pointing to a production batch key, and the NewKeyRef 
(NewKeyRef - refer to Section 32.2.1 ) pointing to either a write-parameter key, or a fill/refill key, or a 
transfer key, or a sequence key. The outputs from the GetProgramKey (signature and encrypted 

20 New Key) is passed in to ReplaceKey function of the Parameter Upgrader QA Device. 

32.3.2.2 Setting up the MO field in m 

The upgrade value field and the count-remaining field must be defined and set in the upgrade QA 
Device using the sequence described in Section 32.2.3. 

32.3.2.3 Writing upgrade value to the upgrade field 

25 The upgrade value is written to upgrade field using the write-parameter key. The upgrade QA 
Device and the trusted QA Device writing to it, share the write-parameter key or a variant write- 
parameter key between them i.e B.Km = A.K^or B.Km = FormKeyVariant(A.Kn2, B.ChipId), where B 
is the upgrade QA Device and A is the trusted QA Device. The command sequence used is 
described in Table 331 . 

30 32. 3. 2. 4 Transferring count-remaining amounts 

Finally, the logical count-remaining amounts are transferred to the count-remaining field using the 
sequence described in Section 31 .7. 

The QACo will also transfer to the ComCo's upgrade QA Device using the command sequence in 
Table 331. 

35 For a successful transfer from QACo to ComCo, ComCo and QACo must share a common key or a 
variant key be i.e ComCo.Km = QACo.K^or ComCo.Kni = FormKeyVariant(QACo.Kn2 
,ComCo.Chipld). Km is the fill/refill key for the ComCo upgrade QA Device. 
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32.3.2.5 Setting up sequence data fields 

The Parameter Upgrader OA Device has sequence data fields SEQ_1 and SEQ_2 (as described in 
Section 27) because its count-remaining fields can be refilled as well. These two fields must be 
initialised to OxFFFFFFFF, refer to Section 27 for details. 
5 The Parameter Upgrader OA Device and the trusted OA Device writing to it, share the sequence 
key or a variant sequence key between them i.e B.Km = A.K^or B.Km = FormKeyVariant(A.Kn2, 
B.ChipId), where B is the Parameter Upgrader OA Device and A is the trusted QA Device. The 
command sequence used is described in Table 331 . 
32.4 Setting up the key programmer 
1 0 The key programming QA Device is set up to replace keys in other QA Devices. 
Each key programming QA Device must go through the following set up: 

o The key programming QA Device must be instantiated to factory defaults. Refer to Section 
32.1 . At the end of instantiation the key programming QA Device has production batch keys 
and no key replacement data. 
15 o The key programming QA Device must be programmed with the appropriate keys and key 
replacement map before it can start to replace keys in other QA Devices. 

32.4.1 Setting up the keys 

The key programming QA Device must be programmed with the key replacement map key. The key 
replacement map key is described in details in Section 24. 
20 The key programming QA Device must programmed with the old and new keys for the QA Devices 
it is going to perform key replacement on. 

Each of the keys is set in the key programming QA Device using the sequence described in Section 
32.2.1. 

32.4.2 Setting up key replacement map field information 

25 First the key replacement map field information is worked out as per Section 24.1 . This field 
information is set in M1 as per the sequence described Section 32.2.3. 

32.4.3 Setting up key replacement map 

Finally, the key replacement map field must be written with the valid mapping using the key 
replacement map key. The key programming QA Device and the trusted QA Device writing to it 
30 must share the key replacement map key or a variant of the key replacement map key between 
them. 

For a successful write of the key replacement map B.K n1 = A.Kn2 or B.K n1 = FormKeyVariantfA.K,*, 
B.ChipId), where B is the key replacement QA Device and A is the trusted QA Device. The 
command sequence used is described in Table 331. 
35 Appendix A: Field Types 
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Table 332 lists the field types that are specifically required by the OA Chip Logical Interface and 
therefore apply across all applications. Additional field types are application specific, and are 
defined in the relevant application documentation. 

Table 332. Predefined Field Types 

5 



Value 


Type 


Description ; 


0x0000 


0 


Non-initialised (default value after final program load) 


0x0001 


TYPE_PREAUTH 


Defines a preauth field in an Ink QA Device 


0x0002 


TYPE_COUNT_REMAININ 
G 


Defines a countRemaining field in an Parameter 
Upgrader QA Device 


0x0003 


TYPE_SEQ_1 


Defines a sequence data field SECM in an Ink QA 
Device 

or in a Printer QA Device or in an upgrader QA Device 


0x0004 


TYPE_SEQ_2 


Defines a sequence data fields SEQ_2 in an Ink QA 
Device 

or in a Printer QA Device or in an upgrader QA Device 


0x0005 


TYPE_KEY_MAP 


Defines a key replacement map in a Key Programmer 
QA Device 


0x0006 

and 

above 


reserved 


reserved for future use 



Appendix B: Key and field definition for different QA Devices 
B. 1 Parameter Upgrader QA Device 
B. 1 . 1 Peer to peer QA Device 
1 0 Table 333. Key definitions for a peer to peer Parameter Upgrader QA Device 



Key 
Name 


Purpose 


Fill/refill Key 


This key has is used for upgrading count-remaining values when the 
upgrade QA Device is upgraded by another upgrade QA Device and is also 
used to decrement the count-remaining when upgrading other QA Devices. 


Sequence Key 


This key is used to initialise sequence data fields SEQ_1 and SEQ_2 to 
OxFFFFFFF. 


Write Parameter 
Key 


This key is used to write the upgrade value to the Parameter Upgrader QA 
Device. 
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Table 334. Field definitions for a peer to peer Parameter Upgrader OA Device 



Field 
Name 


Purpose 


Field Attrinutes 
Type 


KeyNum 


A a 
RW 


NA b 
RW 


KPerrns 0 


EndPos 
(Size) 


Count 

Remainin 

g 


The field stores 
the number of 
times the 
Parameter 
Upgrader QA 
Device is 
permitted to 
upgrade a printer 
QA Device. 


TYPE_COUNT_REMAINI 
NG 


SN l fill/refill key 


1 


0 


KPerms[K 
N*] = 1 
Rest are 0 


Depends 
on the 
maximum 
number 
of 

upgrades 
that 
can be 
stored. 


Upgrade 
Value 


This stores the 
value that is 
copied from the 
Parameter 
Upgrader QA 
Device to the 
field being 
upgraded on the 
printer QA 
Device during the 
upgrade 


Must define the type of the 

upgrade value 

i.e TYPE_PRINT_SPEED d 


SN f write-parameter 
key 


1 


0 


KPerms[K 
NT] = 0 
Rest are 0 
as well 


Set as per 

upgrade 

value. 


SEQJ 


This field holds 
the data for 
sequence data 
field SEQ_1 
when the 
Parameter 
Upgrader QA 
Device is being 
upgraded by 


TYPE SEQ_1 


SN f sequence key 


1 


0 


KPerms[K 
N*] = 0 
KPerms[fill 
/refill 8 ] = 1 
Rest are 0 
as well. 


Typically 
32 bit. 



918 





another 
Parameter 
Upgrader Refill 
QA Device. 














SEQJ 


This field holds 
the data for 
sequence data 
fieldsSEQ_2 
when the 
Parameter 
Upgrader QA 
Device is being 
upgraded by 
another 
Parameter 
Upgrader Refill 
QA Device. 


TYPE_SEQ_2 


SN sequence key 


1 


0 


KPerms[K 
NT] = 0 
KPerms[fill 
/refill 8 ] = 1 
Rest are 0 
as well. 


Typically 
32 bit. 



a. Authenticated Read Write permission 

b. Non-authenticated ReadWrite permission 

c. KeyPerms 

5 d. This is a sample type only 

e. KeyNum 

f. Key Slot Number 

g. Fill/Refill key has authenticated decrement-only permission to the sequence data fields 

1 0 B.1 .2 Heirarchical Transfer QA Device 
Key definitions 

Table 335. Key definitions for a Parameter Upgrader QA Device (transferring down 
the heirachy) 



Key 
Name 


Purpose 


Transfer Key 


This key is used to decrement the count-remaining when upgrading other 
QA Devices. 


Fill/refill Key 


This key has is used for upgrading count-remaining values when the 
Parameter Upgrader QA Device is upgraded by another Parameter 
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Upgrader QA Device Refill QA Device. 


Sequence Key 


This key is used to initialise sequence data fields SEQ_1 and SEQ_2 to 
OxFFFFFFF. 


Write Parameter 
Key 


This key is used to write the upgrade value to the Parameter Upgrader QA 
Device. 



Field definitions 

Table 336. Field definitions for Parameter Upgrader QA Device transferring down 
the hierachy 

5 



Field 


Purpose 


Field Attrinutes 








Name 
















Type 


KeyNum 


A a 


NA b 


KPerms c 


EndPo 










RW 


RW 




s(Size 
) 


Count 


The field stores the 


TYPECOUNTREMAINI 


SN l fill/refill 


1 


0 


KPerms[KN*] 


Depen 


Remaining 


number of times 


NG 


key 






= 0 


ds on 




the Parameter 










K_Perms[Trans 


the 




Upgrader QA 










ferKey]= 1 


maxi 




Device is permitted 










Rest are 0 


mum 




to upgrade a printer 












numbe 




QA Device. 












r 
















of 
















upgra 
















des 
















that 
















can be 
















stored. 


Upgrade 


This stores the 


Must define the type of 


SN'write- 


1 


0 


KeyPerms[K 


Set 


Vaiue 


value that is 


the 


parameter 






N e ] = 0 


as 




copied from the 


upgrade value 


key 






Rest are 0 


per 




Parameter 


i.e 










upgra 




Upgrader QA 


TYPE_PRINT_SPEED d 










de 




Device to the 












value. 




field being 
















upgraded on the 
















printer QA 
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Device during the 
upgrade 














SEQ_1 


This field holds 
the data for 
sequence data 
fields SEQ_1 
when the 
Parameter 
Upgrader QA 
Device is being 
upgraded by 
another 
Parameter 
Upgrader Refill 
QA Device. 


TYPE_SEQ_1 


SN r sequence 
key 


1 


0 


KPermsfKN*] 
= 0 

KPerms[fill/re 
fill 9 ] = 1 
Rest are 0 as 
well. 


Typic 
ally 
32 bit. 


SEQ_2 


This field holds 
the data for 
sequence data 
fields SEQ_2 
when the 
Parameter 
Upgrader QA 
Device is being 
upgraded by 
another 
Parameter 
Upgrader Refill 
QA Device. 


TYPE_SEQ_2 


SN r sequence 
key 


1 


0 


KPermstKN 6 ] 
= 0 ! 
KPerms[fill/re 
fill 9 ] = 1 
Rest are 0 as 
well. 


Typic 
ally 
32 bit. 



a. Authenticated Read Write permission 

b. Non-authenticated Read Write permission 

c. KeyPerms 

5 d. This is a sample type only 

e. KeyNum 

f. Key Slot Number 

g. Fill/Refill key has authenticated decrement-only permission to the sequence data fields 



10 
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B.2 Ink Refill OA Device 
B.2.1 Peer to peer OA Device 
Key definitions 

Table 337. Key definitions for a peer to peer Ink Refill OA Device 

5 



Key 
Name 


Purpose 


Fill/refill Key 


This key has is used for filling/refilling ink-remaining values when the Ink 
Refill QA Device is upgraded by another Ink Refill QA Device and is also 
used to decrement from the ink-remaining when transferring ink to other 
QA Devices (typically Ink QA Device). 


Sequence Key 


This key is used to initialise sequence data fields SEQ_1 and SEQ_2 to 
OxFFFFFFF. 



Field definitions 

Table 338. Field definitions for a peer to peer Ink Refill QA Device 

10 



Field 
Name 


Purpose 


Field Attrinutes 
Type 


Key 
Num 


A a 
RW 


NA b 
RW 


KeyPerms 0 


EndPos(Size) 


Ink 

Remainin 
g 


The field stores the 
amount of 

logical ink-remaining in 
the 

ink refill QA Device. 


Must define the 
type of Ink 

TYPEHIGHQUA 
LITY_BLACK_IN 
K d 


SN l fill/refill 
key 


1 


1 


KeyPerms[K 
N*] = 1 
Rest are 0 


Depends on 
the 

maximum 
amount 
of ink that 
can be stored 
and 

the storage 
resolution 
i.e in pico 
litres or 
in micro 
litres. 


SEQJ 


This field holds the data 
for 


TYPE_SEQ_1 


SN f sequence 
key 


1 


0 


KPermstKN* 

] = o 


Typically 32 
bit. 
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sequence data field 
SEQJ 

when the Ink Refill QA 
Device 

is being filled/refilled 
by another 

Ink Refill QA Device. 










KPerms[fill/r 
efill 8 ] = 1 
Rest are 0 as 
well. 




SEQJ 


This field holds the data 
for 

sequence data field 
SEQ_2 

when the Ink Refill QA 
Device 

is being filled/refilled 
by another 

Ink Refill QA Device. 


TYPE_SEQ_2 


SN* sequence 
key 


1 


0 


KPenns[KN* 

] = o 

KPerms[fill/r 
efill g ] = 1 
Rest are 0 as 
well. 


Typically 32 
bit. 



a. Authenticated ReadWrite permission 

b. Non-authenticated ReadWrite permission 

c. Decrement-Only For Keys 
5 d. This is a sample type only 

e. KeyNum 

f. Key Slot Number 

g. Fill/Refill key has authenticated decrement-only permission to the sequence data fields 
B.2.2 Heirarchical Transfer QA Device 

1 0 Key definitions 

Table 339. Key definitions for a ink refill QA Device (transferring down the heirachy) 



Key 
Name 


Purpose 


Transfer Key 


This key is used to decrement from the ink-remaining when transferring ink 
to other QA Devices . 


Fill/refill Key 


This key has is used for filling/refilling ink-remaining values when the Ink 
Refill QA Device is upgraded by another Ink Refill QA Device. 


Sequence Key 


This key is used to initialise sequence data fields SEQ_1 and SEQ_2 to 
OxFFFFFFF. 
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Field definitions 

Table 340. Field definitions for a Ink Refill QA Device (transferring down the 
heirachy) 



Field 
Name 


Purpose 


Field Attrinutes 
Type 


KeyNum 


A a 
RW 


NA b 
RW 


KeyPerms c 


EndPos( 
Size) 


Ink 

Remainin 
g 


The field stores the 
amount 
of logical ink- 
remaining in the 
Ink Refill QA 
Device. 


Must define the type 

of Ink 

e.g- 

TYPE_HIGHQUALI 
TY_BLACK_ENK d 


SN 1 fill/refill 
key 


1 


0 


KPerms[KN*] = 0 
KPerms[Transfer 
Key] = 1 
Rest are 0 


Depends 
on the 
maximu 
m 

amount 
of ink 
that can 
be 

stored 

and 

the 

storage 

resolutio 

n 

i.e in 
pico 
litres or 
in micro 
litres. 


SEQJ 


This field holds the 
data for 

sequence data field 
SEQ_1 

when the Ink Refill 
QA Device 
is being 

filled/refilled by 

another 

Ink Refill QA 


TYPE_SEQ_1 


SN 1 sequence 
key 


1 


0 


KPerms[KN*] = 0 
KPerms[fill/refill 8 ] 
= 1 

Rest are 0. 


Typicall 
y 32 bit. 
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Device. 














SEQJ 


This field holds the 


TYPE_SEQ_2 


SN* sequence 


1 


0 


KPermsfKN*] = 0 


Typicall 




data for 




key 






KPermsffill/refill 8 ] 


y 32 bit. 




sequence data field 










= 1 






SEQ_2 










Rest are 0. 






when the Ink Refill 
















QA Device 
















is being 
















filled/refilled by 
















another 
















Ink Refill QA 
















Device. 















a. Authenticated Read Write permission 

b. Non-authenticated ReadWrite permission 

c. KeyPerms 

5 d. This is a sample type only 

e. KeyNum 

f. Key Slot Number 

g. Fill/Refill key has authenticated decrement-only permission to the sequence data fields 
B.3 Key programming QA Device 

1 0 B.3.1 Key definitions 

Table 341 . Key definitions for a Key Programming QA Device 



Key 
Name 


Purpose 


Key replacement map 
Key 


This key is used to write the key replacement map. 


Old Keys 


These are the old keys of the QA Device whose keys will be replaced by 
the Key Programming QA Device. 


New Keys 


These are the new keys of the QA Device whose old keys will be replaced 
by the Key Programming QA Device. 



B.3.2 Field definitions 
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Table 342. Field definitions for a key replacement OA Device 



Field 


Purpose 


Field Attrinutes 












Name 




















Type 


KeyNum 


A a 
RW 


NA b 
RW 


KPerms c 


EndPo 

s 

(Size) 


Key 


This defines the 


TYPE_KEY_M 


Key Replacement 


1 


0 


KPerms[KN° 


2 


replacement 


mapping 


AP 


Map key 






1 = 0 


words 


map 


between the old 
key and the new 
key for the OA 
Device whose old 
key will be 
replaced by the 
new key. 










Rest are 0 


(64 
bits) 



a. Authenticated ReadWrite permission 
5 b. Non-authenticated ReadWrite permission 

c. KeyPerms 

d. KeyNum 

B.4 Ink QA Device 
B.4.1 Key definitions 
1 0 Table 343. Key definitions for a Ink QA Device 



|Key 
Name 


Purpose 


Fill/refill Key 


This key is used for fiil/refilling ink-remaining amount in the ink QA Device. 


Ink usage Key 


This key is verifying the data read from the ink QA Device and for writing 
preauth data. 


Sequence Key 


This key is used to initialise sequence data fields SEQ_1 and SEQ_2 to 
OxFFFFFFF. 
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B.4.2 Field definitions 

Table 344. Field definitions for a Ink OA Device 



Field 
Name 


Purpose 


Field Attrinutes 
Type 


Key 
Num 


A a 
RW 


NA b 
RW 


KPerms c 


EndPos 
(Size) 


Ink 

Remaining 


The amount of logical 
ink-remaining in the 
ink QA Device. 
More than one ink- 
remaining field may be 
present depending on 
the number of physical 
inks stored in the ink 
cartridge. 


Must define the type 

of Ink 

i.e 

TYP E_HQ_B LACK 
_INK d 


SN f 

fill/refill 
key 


1 


1 


KPerms[KN*] = 
1 

Rest are 0 


Depends 
on the 
maximum 
amount 
of ink that 
can be 
stored 
and 

the storage 
resolution 
i.e in pico 
litres or 
in micro 
litres. 


Preauth 


This field defines the 
preauth value. 


TYPEPREAUTH 


SN'ink 
usage key 


0 


1 


KPerms[KN*] = 
0 

Rest are 0 


Depends 
on preauth 
amount. 
Typically 
32 bits, 
may be 64 
bits to 
accomodat 
e 

larger 

preauth 

amounts. 


SEQJ 


This field holds the 
data for 

sequence data field 


TYPE_SEQ_1 


SN l 

sequence 
Jcey 


1 


0 


KPermstKN*] = 
0 

KPerms[fill/refil 


Typically 
32 bit. 
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SEQ_1 

when the Ink QA 
Device 

is being filled/refilled 
by a Ink Refill QA 

Device. 










l 8 ]^ 1 
Rest are 0. 




SEQJ 


This field holds the 


TYPE_SEQ_2 


SN 1 


1 


0 


KPerms[KN*] = 


Typically 




data for 




sequence 






0 


32 bit. 




sequence data field 




key 






KPermsffill/refil 






SEQ_2 










1 8 ] = 1 






when the Ink QA 










Rest are 0. 






Device 
















is being filled/refilled 
















by another 
















Ink Refill QA Device. 















a. Authenticated Read Write permission 

b. Non-authenticated ReadWrite permission 

c. KeyPerms 

5 d. This is a sample type only 

e. KeyNum 

f. Key Slot Number 

g. Fill/Refill key has authenticated decrement-only permission to the sequence data fields 

1 0 B.5 Printer QA Device 
B.5.1 Key definition 



Table 345. Key definitions for a Printer QA Device 



Key 
Name 


Purpose 


Upgrade key 
(fill/refill key) 


This key is used for writing / upgrading the functional parameter. 


Ink usage Key 


This key is verifying the data read from the Ink QA Device. 


Sequence Key 


This key is used to initialise sequence data fields SEQ_1 and SEQ_2 to 
OxFFFFFFF. 
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PECID/SOPECID 
Key 



This key is used to verify the data read from the printer OA Device. This 
key is unique to each printer. Also used to translate data from the ink QA 
Device to the trusted printer system QA Device. 



B.5.2 Field definition 

Table 346. Field definitions for a Printer QA Device 



Field 
Name 


Purpose 


Field Attrinutes 
Type 


Key 
Num 


A a 
RW 


NA b 
RW 


KPerms 0 


EndPo 
s 

(Size) 


Functional 
parameter 


The field stores an 
upgradeable functional 
parameter. 
More than one 
functional parameter 
can be stored in the 
printer QA Device. 


Must define the type of 

print speed 

i.e 

TYPEJPRINT_SPEED d 


SN f 

fill/refill 
key 


1 


0 


KPenns[KN* 

] = o 

Rest are 0 


Set as 
per 

functio 
nal 

para me 
ter. 


SEQJ 


This field holds the 
data for 

sequence data field 
SEQ_1 

when the Printer QA 
Device 

is being filled/refilled 
by a Parameter 
Upgrader QA Device. 


TYPE_SEQ_1 


SN 1 

sequence 
key 


1 


0 


KPennsfKN* 
] = 0 

KPerms[fill/r 
efill 8 ] = 1 
Rest are 0. 


Typicall 

y32 

bit. 


SEQJ 


This field holds the 
data for 

sequence data field 
SEQ_2 

when the Printer QA 
Device 

is being filled/refilled 
by another 
Parameter Upgrader 


TYPE_SEQ_2 


SN f 

sequence 
key 


1 


0 


KPermstKN* 

] = o 

KPerms[fill/r 
efill 8 ] = 1 
Rest are 0. 


Typicall 

y32 

bit. 
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QA Device. 















a. Authenticated ReadWrite permission 

b. Non-authenticated ReadWrite permission 

c. KeyPerms 

5 d. This is a sample type only 

e. KeyNum 

f. Key Slot Number 

g. Fill/Refill key has authenticated decrement-only permission to the sequence data fields 

1 0 B.6 Trusted printer system QA Device 
B.6.1 Key definition 



Table 347. 



Key 
Name 


Purpose 


PECID/SOPECID 
Key 


This key is used to verify the data read from 

the printer QA Device. 

This key is unique to each printer. 

This key is also used for verifying translated 

data from the ink QA Device. 



15 
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Introduction 

1 Background 

This document describes a QA Chip that can be used to hold contains authentication keys together 
5 with circuitry specially designed to prevent copying. The chip is manufactured using a standard 

Flash memory manufacturing process, and is low cost enough to be included in consumables such 
as ink and toner cartridges. The implementation is approximately 1mm 2 in a 0.25 micron flash 
process, and has an expected die manufacturing cost of approximately 10 cents in 2003. 
Once programmed, the QA Chips as described here are compliant with the NSA export guidelines 
1 0 since they do not constitute a strong encryption device. They can therefore be practically 
manufactured in the USA (and exported) or anywhere else in the world. 

Note that although the QA Chip is designed for use in authentication systems, it is microcoded, and 
can therefore be programmed for a variety of applications. 

2 Nomenclature 

1 5 The following symbolic nomenclature is used throughout this document: 
Table 348. Summary of symbolic nomenclature 



Symbol 


Description 


F[X] 


Function F, taking a single parameter X ! 


F[X,Y] 


Function F, taking two parameters, X and Y 


X | Y 


X concatenated with Y 


XaY 


Bitwise X ANDY 


X v Y 


Bitwise X OR Y (inclusive-OR) 


xe y 


Bitwise X XOR Y (exclusive-OR) 


-.X 


Bitwise NOT X (complement) 


X <- Y 


X is assigned the value Y 


X<-{Y, Z} 


The domain of assignment inputs to X is Y and Z 


X = Y 


X is equal to Y 


X* Y 


X is not equal to Y 


Ox 


Decrement X by 1 (floor 0) 


fix 


Increment X by 1 (modulo register length) 


Erase X 


Erase Flash memory register X 


SetBits[X, Y] 


Set the bits of the Flash memory register X based on Y 


Z <- ShiftRight[X, 
Y] 


Shift register X right one bit position, taking input bit 
from Y and placing the output bit in Z 
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3 Pseudocode 

3.1 Asynchronous 

The following pseudocode: 

var = expression 

5 means the var signal or output is equal to the evaluation of the expression. 

3.2 Synchronous 

The following pseudocode: 
var <— expression 

means the var register is assigned the result of evaluating the expression during 
10 this cycle. 

3.3 Expression 

Expressions are defined using the nomenclature in Table 348 above. Therefore: 
var = (a = b) 

is interpreted as the var signal is 1 if a is equal to b, and 0 otherwise. 
15 4 Diagrams 

Black lines are used to denote data, while red lines are used to denote 1-bit control-signal lines. 
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Logical Interface 
5 Introduction 

The QA Chip has a physical and a logical external interface. The physical interface defines how the 
OA Chip can be connected to a physical System, while the logical interface determines how that 
5 System can communicate with the QA Chip. This section deals with the logical interface. 
5.1 Operating Modes 

The QA Chip has four operating modes - Idle Mode, Program Mode, Trim Mode and Active Mode. 

Active Mode is entered on power-on Reset when the fuse has been blown, and whenever a 

specific authentication command arrives from the System. Program code is only executed in 
10 Active Mode. When the reset program code has finished, or the results of the command have 

been returned to the System, the chip enters Idle Mode to wait for the next instruction. 

Idle Mode is used to allow the chip to wait for the next instruction from the System. 

Trim Mode is used to determine the clock speed of the chip and to trim the frequency during 

the initial programming stage of the chip (when Flash memory is garbage). The clock 
1 5 frequency must be trimmed via Trim Mode before Program Mode is used to store the 

program code. 

Program Mode is used to load up the operating program code, and is required because the 
operating program code is stored in Flash memory instead of ROM (for security reasons). 

Apart from while the QA Chip is executing Reset program code, it is always possible to interrupt the 
20 QA Chip and change from one mode to another. 

5.1.1 Active Mode 

Active Mode is entered in any of the following three situations: 
power-on Reset when the fuse has been blown 

receiving a command consisting of a global id write byte (0x00) followed by the ActiveMode 
25 command byte (0x06) 

receiving a command consisting of a local id byte write followed by some number of bytes 
representing opcode and data. 
In all cases, Active Mode causes execution of program code previously stored in the flash memory 
via Program Mode. 

30 If Active Mode is entered by power-on Reset or the global id mechanism, the QA Chip executes 
specific reset startup code, typically setting up the local id and other IO specific data. The reset 
startup code cannot be interrupted except by a power-down condition. The power-on reset startup 
mechanism cannot be used before the fuse has been blown since the QA Chip cannot tell whether 
the flash memory is valid or not. In this case the globalid mechanism must be used instead. 

35 If Active Mode is entered by the local id mechanism, the QA Chip executes specific code depending 
on the following bytes, which function as opcode plus data. The interpretation of the following bytes 
depends on whatever software happens to be stored in the QA Chip. 
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5.1.2 Idle Mode 

The QA Chip starts up in Idle Mode when the fuse has not yet been blown, and returns to Idle Mode 
after the completion of another mode. When the QA Chip is in Idle Mode, it waits for a command 
from the master by watching the low speed serial line for an id that matches either the global id 
(0x00), or the chip's local id. 

If the primary id matches the global id (0x00, common to all QA Chips), and the following byte 
from the master is the Trim Mode id byte, and the fuse has not yet been blown, the QA Chip 
enters Trim Mode and starts counting the number of internal clock cycles until the next byte is 
received. Trim Mode cannot be entered if the fuse has been blown. 

If the primary id matches the global id (0x00, common to all QA Chips), and the following byte 
from the master is the Program Mode id byte, and the fuse has not yet been blown, the QA 
Chip enters Program Mode. Program Mode cannot be entered if the fuse has been blown. 
If the primary id matches the global id (0x00, common to ail QA Chips), and the following 
byte from the master is the Active Mode id bytes, the QA Chip enters Active Mode and 
executes startup code, allowing the chip to set itself into a state to subsequently receive 
authentication commands (includes setting a local id and a trim value). 
If the primary id matches the chip's local id, the QA Chip enters Active Mode, allowing the 
subsequent command to be executed. 

The valid 8-bit serial mode values sent after a global id are as shown in Table 349: 
Table 349. Command byte values to place chip in specific mode 



Value 


Interpretation 


10101011 
(OxAB) 


Trim Mode (only functions when the fuse has not been blown) 


10001101 
(OxAD) 


Program Mode (only functions when the fuse has not been blown) 


00000110 
(0x06) 


Active Mode (resets the chip & loads the localld) 



5.1.3 Trim Mode 

Trim Mode is enabled by sending a global id byte (0x00) followed by the Trim Mode command byte 
25 (OxAB). Trim Mode can only be entered while the fuse has not yet been blown. 

The purpose of Trim Mode is to set the trim value (an internal register setting) of the internal ring 
oscillator so that Flash erasures and writes are of the correct duration. This is necessary due to the 
2:1 variation of the clock speed due to process variations. If writes an erasures are too long, the 
Flash memory will wear out faster than desired, and in some cases can even be damaged. Note 



10 



15 



20 
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that the 2:1 variation due to temperature still remains, so the effective operating speed of the chip is 
7-14 MHz around a nominal 10MHz. 

Trim Mode works by measuring the number of system clock cycles that occur inside the chip from 
the receipt of the Trim Mode command byte until the receipt of a data byte. When the data byte is 
5 received, the data byte is copied to the trim register and the current value of the count is transmitted 
to the outside world. 

Once the count has been transmitted, the QA Chip returns to Idle Mode. 
At reset, the internal trim register setting is set to a known value r. The external user can now 
perform the following operations: 
1 0 • send the global id+write followed by the Trim Mode command byte 

send the 8-bit value v over a specified time t 

send a stop bit to signify no more data 

send the global id+read followed by the Trim Mode command byte 

receive the count c 
1 5 • send a stop bit to signify no more data 

At the end of this procedure, the trim register will be v, and the external user will know the 
relationship between external time t and internal time c. Therefore a new value for v can be 
calculated. 

The Trim Mode procedure can be repeated a number of times, varying both t and v in known ways, 
20 measuring the resultant c. At the end of the process, the final value for v is established (and stored 

in the trim register for subsequent use in Program Mode). This value v must also be written to the 

flash for later use (every time the chip is placed in Active Mode for the first time after power-up). 

For more information about the internal workings of Trim Mode and the accuracy of trim in the QA 

Chip, see Section 1 1 .2 on page 967. 
25 5.1.4 Program Mode 

Program Mode is enabled by sending a global id byte (0x00) followed by the Program Mode 

command byte. 

If the QA Chip knows already that the fuse has been blown, it simply does not enter Program Mode. 
If the QA Chip does not know the state of the fuse, it determines whether or not the internal fuse 
30 has been blown by reading 32-bit word 0 of the information block of flash memory. If the fuse has 
been blown the remainder of data from the Program Mode command is ignored, and the QA Chip 
returns to Idle Mode. 

If the fuse is still intact, the chip enters Program Mode and erases the entire contents of Flash 
memory. The QA Chip then validates the erasure. If the erasure was successful, the QA Chip 
35 receives up to 4096 bytes of data corresponding to the new program code and variable data. The 
bytes are transferred in order byte 0 to byte^gs- 

Once all bytes of data have been loaded into Flash, the QA Chip returns to Idle Mode. 



935 



Note that Trim Mode functionality must be performed before a chip enters Program Mode for the 
first time. Otherwise the erasure and write durations could be incorrect. 

Once the desired number of bytes have been downloaded in Program Mode, the LSS Master must 
wait for 80ns (the time taken to write two bytes to flash at nybble rates) before sending the new 
5 transaction (e.g. Active Mode). Otherwise the last nybbles may not be written to flash. 
5.1 .5 After Manufacture 

Directly after manufacture the flash memory will be invalid and the fuse will not have been blown. 
Therefore power-on-reset will not cause Active Mode. Trim Mode must therefore be entered first, 
and only after a suitable trim value is found, should Program Mode be entered to store a program. 
1 0 Active Mode can be entered if the program is known to be valid. 
Logical View of CPU 

6 Introduction 

The QA Chip is a 32-bit microprocessor with on-board RAM for scratch storage, on-board flash for 
program storage, a serial interface, and specific security enhancements. 
1 5 The high level commands that a user of an QA Chip sees are all implemented as small programs 
written in the CPU instruction set. 

The following sections describe the memory model, the various registers, and the instruction set of 
the CPU. 

7 Memory Model 

20 The QA Chip has its own internal memory, broken into the following conceptual regions: 

RAM variables (3Kbits = 96 entries at 32-bits wide), used for scratch storage (e.g. HMAC- 
SHA1 processing). 

Flash memory (8Kbytes main block + 128 bytes info block) used to hold the non-volatile 
authentication variables (including program keys etc), and program code. Only 4 KBytes + 64 
25 bytes is visible to the program addressing space due to shadowing. Shadowing is where half 

of each byte is used to validate and verify the other half, thus protecting against certain forms 
of physical and logical attacks. As a result, two bytes are read to obtain a single byte of data 
(this happens transparently). 
7.1 RAM 

30 The RAM region consists of 96 x 32-bit words required for the general functioning of the QA Chip, 
but only during the operation of the chip. RAM is volatile memory: once power is removed, the 
values are lost. Note that in actual fact memory retains its value for some period of time after power- 
down, but cannot be considered to be available upon power-up. This has issues for security that are 
addressed in other sections of this document. 

35 RAM is typically used for temporary storage of variables during chip operation. Short programs can 
also be stored and executed from the RAM. 
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RAM is addressed from 0 to 5F. Since RAM is in an unknown state upon a RESET (RstL), program 
code should not assume the contents to be 0. Program code can, however, set the RAM to be a 
particular known state during execution of the reset command (guaranteed to be received before 
any other commands). 
5 7.2 Flash variables 

The flash memory region contains the non-volatile information in the QA Chip. Flash memory 
retains its value after a RESET or if power is removed, and can be expected to be unchanged when 
the power is next turned on. 

Byte 0 of main memory is the first byte of the program run for the command dispatcher. Note that 
1 0 the command dispatcher is always run with shadows enabled. 

Bytes 0-7 of the information block flash memory is reserved as follows: 

byte 0-3 = fuse. A value of 0x5555AAAA indicates that the fuse has been blown (think of a 

physical fuse whose wire is no longer intact). 

bytes 4-7 = random number used to XOR all data for RAM and flash memory accesses 

1 5 After power-on reset (when the fuse is blown) or upon receipt of a globalld Active command, the 32- 
bit data from bytes 4-7 in the information block of Flash memory is loaded into an internal ChipMask 
register. In Active Mode (the chip is executing program code), all data read from the flash and RAM 
is XORed with the ChipMask register, and all data written to the flash and RAM is XORed with the 
ChipMask register before being written out. This XORing happens completely transparently to the 

20 program code. Main flash memory byte 0 onward is the start of program code. Note that byte 0 
onward needs to be valid after being XORed with the appropriate bytes of ChipMask. 
Even though CPU access is in 8-bit and 32-bit quantities, the data is actually stored in flash a 
nybble-at-a-time. Each nybble write is written as a byte containing 4 sets of b/-nb pairs. Thus every 
byte write to flash is writing a nybble to real and shadow. A write mask allows the individual 

25 targetting of nybble-at-a-time writes. 

The checking of flash vs shadow flash is automatically carried out each read (each byte contains 
both flash and shadow flash). If all 8 bits are 1, the byte is considered to be in its erased form 1 , and 
returns 0 as the nybble. Otherwise, the value returned for the nybble depends on the size of the overall access 
and the setting of bit 0 of the 8-bit WriteMask. 

30 • All 8-bit accesses (i.e. instruction and program code fetches) are checked to ensure that each 
byte read from flash is 4 sets of b/-.b pairs. If the data is not of this form, the chip hangs until 
a new command is issued over the serial interface. 

With 32-bit accesses (i.e. data used by program code), each byte read from flash is checked 
to ensure that it is 4 sets of b/-.b pairs. A setting of WriteMasko = 0 means that if the data is 



1 TSMC's flash memory has an erased state of all 1s 



937 



not valid, then the chip will hang until a new command is issued over the serial interface. A 
setting of WriteMasko = 1 means that each invalid nybble is replaced by the upper nybble of 
the WriteMask. This allows recovery after a write or erasure is interrupted by a power-down. 
8 Registers 

5 A number of registers are defined for use by the CPU. They are used for control, temporary storage, 
arithmetic functions, counting and indexing, and for I/O. 

These registers do not need to be kept in non-volatile (Flash) memory. They can be read or written 
without the need for an erase cycle (unlike Flash memory). Temporary storage registers that 
contain secret information still need to be protected from physical attack by Tamper Prevention and 
1 0 Detection circuitry and parity checks. 

All registers are cleared to 0 on a RESET. However, program code should not assume any RAM 
contents have any particular state, and should set up register values appropriately. In particular, at 
the startup entry point, the various address registers need to be set up from unknown states. 

8.1 GO 

15 A 1-bit GO register is 1 when the program is executing, and 0 when it is not. Programs can clear the 
GO register to halt execution of program code once the command has finished executing. 

8.2 Accumulator and Z flag 

The Accumulator is a 32-bit general-purpose register that can be thought of as the single data 
register. It is used as one of the inputs to all arithmetic operations, and is the register used for 
20 transferring information between memory registers. 

The Z register is a 1-bit flag, and is updated each time the Accumulator is written to. The Z register 
contains the zero-ness of the Accumulator. Z = 1 if the last value written to the Accumulator was 0, and 0 
if the last value written was non-0. 

Both the Accumulator and Z registers are directly accessible from the instruction set. 
25 8.3 Address registers 

8.3.1 Program Counter Array and Stack Pointer 

A 12-ievel deep 12-bit Program Counter Array (PCA) is defined. It is indexed by a 4-bit Stack Pointer 
(SP). The current Program Counter (PC), containing the address of the currently executing 
instruction, is effectively PCA[SP]. A single register bit, PCRamSel determines whether the program is 

30 executing from flash or RAM (0 = flash, 1 = RAM). 

The PC is affected by calling subroutines or returning from them, and by executing branching 
instructions. The SP is affected by calling subroutines or returning from them. There is no bounds 
checking on calling too many subroutines: the oldest entry in the execution stack will be lost. 
The entry point for program code is defined to be address 0 in Flash. This entry point is used 

35 whenever the master signals a new transaction. 



938 



8.3.2 A0-A3 

There are 4 8-bit address registers Each register has an associated memory mode bit designating 
the address as in Flash (0) or RAM (1). 

When an An register is pointing to an address in RAM, it holds the word number. When it is pointing 
5 to an address in Flash, it points to a set of 32-bit words that start at a 128-bit (16 byte) alignment. 
The AO register has a special use of direct offset e.g. access is possible to (A0),0-7 which is the 32- 
bit word pointed to by AO offset by the specified number of words. 

8.3.3 WriteMask 

The WriteMask register is used to determine how many nybbles will be written during a 32-bit write 
10 to Flash, and whether or not an invalid nybble will be replaced during a read from Flash. 

During writes to flash, bit n (of 8) determines whether nybble n is written. The unit of writing is a 
nybble since half of each byte is used for shadow data. A setting of OxFF means that all 32-bits will 
be written to flash (as 8 sets of nybble writes). 

During 32-bit reads from flash (occurs as 8 reads), the value of WriteMasko is used to determine 
1 5 whether a read of invalid data is replaced by the upper nybble of WriteMask. If 0, a read of invalid 
data is not replaced, and the chip hangs until a new command is issued over the serial interface. If 
1 , a read of invalid data is replaced by the upper nybble of the WriteMask. 

Thus a WriteMask setting of 0 (reset setting) means that no writes will occur to flash, and all reads 
are not replaced (causing the program to hang if an invalid value is encountered). 
20 8.4 Counters 

A number of special purpose counters/index registers are defined: 

Table 350. Counter/Index registers 



Name 


Register 
Size 


Bits 


Description 


C1 


1 x 3 


3 


Counter used to index arrays and general 
purpose counter 


C2 


1 x6 


6 


General purpose counter and can be used to 
index arrays 



25 All these counter registers are directly accessible from the instruction set. Special instructions exist 
to load them with specific values, and other instructions exist to decrement or increment them, or to 
branch depending on the whether or not the specific counter is zero. 

There are also 2 special flags (not registers) associated with C1 and C2, and these flags hold the 
zero-ness of C1 or C2. The flags are used for loop control, and are listed here, for although they are 
30 not registers, they can be tested like registers. 
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Table 351. Flags for testing C1 and C2 



Name 


Description 


C1Z 


1 = C1 is current zero, 0 = C1 is currently non-zero. 


C2Z 


1 = C2 is current zero, 0 = C2 is currently non-zero. 



8.5 RTMP 

5 The single bit register RTMP allows the implementation of LFSRs and multiple precision shift 
registers. 

During a rotate right (ROR) instruction with operand of RB, the bit shifted out (formally bit 0) is written 
to the RTMP register. The bit currently in the RTMP register becomes the new bit 31 of the 
Accumulator. Performing multiple ROR RB commands over several 32-bit values implements a multiple 

1 0 precision rotate/shift right. 

The XRB operand operates in the same way as RB, in that the current value in the RTMP register 
becomes the new bit 31 of the Accumulator. However with the XRB instruction, the bit formally known 
as bit 0 does not simply replace RTMP (as in the RB instruction). Instead, it is XORed with RTMP, and 
the result stored in RTMP, thereby allowing the implementation of long LFSRs. 

1 5 8.6 Registers used for I/O 

Several registers are defined for communication between the master and the QA Chip. These 
registers are Localld, InByte and OutByte. 

Localld (7 bits) defines the chip-specific id that this particular QA Chip will accept commands for. 
InByte (8 bits) provides the means for the QA Chip to obtain the next byte from the master. OutByte (8 
20 bits) provides the means for the QA Chip to send a byte of data to the master. 
From the QA Chip's point of view: 

Reads from InByte will hang until there is 1 byte of data present from the master. 
Writes to OutByte will hang if the master has not already consumed the last OutByte. 
When the master begins a new command transaction, any existing data in InByte and OutByte is lost, 
25 and the PC is reset to the entry point in the code, thus ensuring correct framing of data. 
8.7 Registers used for trimming clock speed 

A single 8-bit Trim register is used to trim the ring oscillaor clock speed. The register has a known 
value of 0x00 during reset to ensure that reads from flash will succeed at the fastest process 
corners, and can be set in one of two ways: 
30 • via Trim Mode, which is necessary before the QA Chip is programmed for the first time; or 

via the CPU, which is necessary every time the QA Chip is powered up before any flash write 

or erasure accesses can be carried out. 
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8.8 Registers used for testing Flash 

There are a number of registers specifically for testing the flash implementation. A single 32-bit 
write to an appropriate RAM address allows the setting of any combination of these flash test 
registers. 

5 RAM consists of 96 x 32-bit words, and can be pointed to by any of the standard An address 

registers. A write to a RAM address in the range 97-127 does nothing with the RAM (reads return 
0), but a write to a RAM address in the range 0x80-0x87 will write to specific groupings of registers 
according to the low 3 bits of the RAM address. A 1 in the address bit means the appropriate part of 
the 32-bit Accumulator value will be written to the appropriate flash test registers. A 0 in the address 
1 0 bit means the register bits will be unaffected. 

The registers and address bit groupings are listed in Table 352: 

Table 352. Flash test registers settable from CPU in RAM address range 0x80- 
0x87 2 



adr 

bitSuperscriptp 
aranumonly 


data bits 


name 


description 


0 


0 


shadowsOff 


0 = shadowing applies (nybble based flash 
access) 

1 = shadowing disabled, 8-bit direct accesses 
to flash. 




1 


hiFlashAdr 


Only valid when shadowsOff = 1 

0 = accesses are to lower 4Kbytes of flash 

1 = accesses are to upper 4 Kbytes of flash 




2 




1 


3 


enableFlashTes 
t 


0 = keep flash test register within the TSMC 
flash IP in its reset state 

1 = enable flash test register to take on non- 
reset values. 




8-4 


flashTest 


Internal 5-bit flash test register within the 
TSMC flash IP (SFC008_08B9_HE). 



This is from the programmer's perspective. Addresses sent from the CPU are byte aligned, so the MRU needs to test 
bit n+2. Similarly, checking DRAM address > 128 means testing bit 7 of the address in the CPU, and bit 9 in the MRU. 

unshadowed 

shadowed 
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If this is written with 0x1 E, then subsequent 
writes will be according to the TSMC write test 
mode. You must write a non-0x1 E value or 
reset the register to exit this mode. 


2 


28-9 


flashTime 


When timerSel is 1 , this value is used for the 
duration of the program cycle within a 
standard flash write or erasure. 1 unit = 16 
clock cycles (16 x 100ns typical). 
Regardless of timerSel, this value is also used 
for the timeout following power down detection 
before the QA Chip resets itself. 1 unit = 1 
clock cycle (= 100ns typical). 
Note that this means the programmer should 
set this to an appropriate value (e.g. 5 /us), just 
as the localld needs to be set 




29 


timerSel 


0 = use internal (default) timings for flash 
writes & erasures 

1 = use flashTime for flash writes and erasures 



When none of the address register bits 0-2 are set (e.g. a write to RAM address 0x80), then invalid 
writes will clear the illChip and retryCount registers. 

For example, set the AO register to be 0x80 in RAM. A write to (A0),0 will write to none of the flash 
5 test registers, but will clear the illChip and retryCount registers. A write to (AO), 7 will write to all of the 
flash test registers. A write to (A0),2 will write to the enableFlashTest and flashTest registers only. A 
write to (A0),4 will write to the flashTime and timerSel registers etc. 

Finally, a write to address 0x88 in RAM will cause a device erasure. If infoBlockSel is 0, then the 
device erasure will only be of main memory. If infoBlockSel is 1, then the device erasure is of both 
1 0 main memory and the information block (which will also clear the ChipMask and the Fuse). 
Reads of invalid RAM areas will reveal information as follows: 

all invalid addresses in RAM (e.g. 0x80) will return the illChip flag in the low bit (illChip is set 
whenever 16 consecutive bad reads occur for a single byte in memory) 
all invalid addresses in RAM with the low address bit set (e.g. 0x81, or (A0),1 when AO holds 
1 5 0x80), will additionally return the most recent retryCount setting (only updated by the chip when 

a bad read occurs), i.e. bit 0 = illChip, bits 4-1 = retryCount. 
8.9 Register summary 

Table 353 provides a summary of the registers used in the CPU. 
Table 353. Register summary 
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Register name 


Description 


#bits 


A[0-3] 


address registers 


49 =36 


Acc 


Accumulator 


32 


C1 


general purpose counter and index 


3 


C2 


general purpose counter and index 


6 


IllChip 


gets set whenever more than 1 5 consecutive bad 
reads from flash occurred (and any program 
executing nas nung; 


1 


inDyie 


input Dyie irom ouisiae wona 


o 




determines whether CPU is executing 


A 
1 


Locana 


determines id for this chip's IO 


"7 


uuttjyte 


output byte to outside world 


Q 

o 




zero flag for last xfer to Acc 


1 




program counter array 


101 O — "i A A 


PCRamSel 


Program code is executing in flash (0) or ram (1) 


1 


RetryCount 


counts the number of retries for bad reads 


4 


RTMP 


bit used to alow multi-word rotations 


1 


SP 


stack pointer into PCA 


4 


Trim 


trims ring oscillator frequency 


8 


flash test registers 


various registers in the embedded flash and flash 
access logic specifically for testing the flash 
memory 


30 


TOTAL (bits) 


295 



8.10 Startup 

Whenever the chip is powered up, or receives a 'write' command over the serial interface, the PC 
5 and PCRamSel get set to 0 and execution begins at 0 in Flash memory. The program (starting at 0) 
needs to determine how the program was started by reading the InByte register. 
If the first byte read is OxFF, the chip is being requested to perform software reset tasks. Execution 
of software reset can only be interrupted by a power down. The reset tasks include setting up RAM 
to contain known startup state information, setting up Trim and locallD registers etc. The CPU signals 
1 0 that it is now ready to receive commands from an external device by writing to the OutByte register. 
An external Master is able to read the OutByte (and any further outbytes that the CPU decides to 
send) if it so wishes by a read using the local Id. 
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Otherwise the first byte read will be of the form where the least significant bit is 0, and bits 7-1 
contain the localld of the device as read over the serial interface. This byte is usually discarded since 
it nominally only has a value of differentiation against a software reset request. The second and 
subsequent bytes contain the data message of a write using the localld. The CPU can prevent 
5 interruption during execution by writing 0 to the localld and then restoring the desired localld at the 
later stage. 

9 Instruction Set 

The CPU operates on 8-bit instructions and typically on 32-bit data items. Each instruction typically 
consists of an opcode and operand, although the number of bits allocated to opcode and operand 
1 0 varies between instructions. 

9.1 Basic Opcodes (Summary) 

The opcodes are summarized in Table 354: 

Table 354. Opcode bit pattern map 



Opcode 


Mnemonic 


Simple Description 


OOOOxxxx 


JMP 


Jump 


OOOlxxxx 


JSR 


Jump subroutine 


OOlOxxxx 


TBR 


Test and branch 


OOllxxxx 


DBR 


Decrement and branch 


OlOOxxxx 


SC 


Set counter to a value 


OlOlxxxx 


ST 


Store Accumulator in specified location 


OllOOOOx 




reserved 


01100010 


JPZ 


Jump to 0 


01100011 


JPI 


Jump indirect 


OllOOlxx 




reserved 


OllOlxxx 


- 


reserved 


01110000 


- 


reserved 


01110001 


ERA 


Erase page of flash memory pointed to by 
Accumulator 


01110010 


JSZ 


Jump to subroutine at at 0 


01110011 


JSI 


Jump subroutine indirect 


01110100 


RTS 


Return from subroutine 


01110101 


HALT 


Stop the CPU 


OlllOllx 




reserved 


Ollllxxx 


LIA 


Load immediate value into address register 


lOOOOxxx 


AND 


Bitwise AND Accumulator 
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1UUU 1XXX 




Bitwise vjk Accumulator 


i nni ww 


AUK 


txciusive-UK Accumulator 


i m n v v w 


Ann 

MUU 


moo a Dii vaiue 10 me Accumulator 


1 Ol T ww 


i n 


Luao Mccurnuiaior 


llOOxxxx 


ROR 


Rotate Accumulator right 


111) 1UXXX 


a Kir^ 
AND 


Bitwise AND Accumulator 


i 1U 1 ixxx 


OR 


Bitwise OR Accumulator K 7 


_L _L _L UUaaa 


AUK 


Bitwise auk Accumulator 


lllOlxxx 


ADD 


Add a 32 bit value to the 
Accumulator Superscriptparanumonly 


llllOxxx 


LD 


Load Accumulator 5>uperscnptparanumon,y 


lllllxxx 


RIA 


Rotate Accumulator into address register 



Table 355 is a summary of valid operands for each opcode. The table is ordered alphabetically by 
opcode mnemonic. The binary value for each operand can be found in the subsequent sections. 
Table 355. Valid operands for opcodes 



Opcode 


Valid operands 


ADD 


immediate value 
(AO), offset 

(An), {C1.C2} [where n = 0-3] 


AND 


immediate value 
(AO), offset 


DBR 


{C1 , C2}, offset 


ERA 




HALT 




JMP 


address 


JPI 




JPZ 




JSI 




JSR 


address 


JSZ 




LIA 


{Flash, Ram}, An [where n = 0-3], {immediate value} 


LD 


immediate value 



Immediate form of instruction 
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(AO), offset 

(An), tui.u^/ [wnere n — u-oj 


no 
UK 


immeoiate value 

/An\ r»ff cot 


RIA 


{Flash, Ram}, An [where n = 0-3] 


KUK 


(inDyte, uuiDyte, writeiviasK, iu, ui, u^, kd, akd, 1,0,0,^4,01/ 


DTC 

K 1 o 




sc 


{C1, C2}, {immediate value} 


ST 


(AO), offset 

(An), [wnere n — u-oj 


TBR 


{0, 1}, offset 


XOR 


immediate value 
(AO), offset 

(An), {C1 ,C2} [where n = 0-3] 



Additional pseduo-opcodes (for programming convenience) are as follows: 

• DEC=ADD OxFF.. 

• INC= ADD 0x01 

5 • NOT=XOR0xFF.. 

• LDZ = LD 0 

• SC {C1 , C2}, Acc = ROR {C1 , C2} 

• RD = ROR Inbyte 

• WR = ROR OutByte 

1 0 • LDMASK = ROR WriteMask 

• LDID = ROR Id 

• NOP = XOR 0 
9.2 Addressing Modes 

The CPU supports a set of addressing modes as follows: 
15 • immediate 

• accumulator indirect 

• indirect fixed 

• indirect indexed 
9.2.1 Immediate 

20 In this form of addressing, the operand itself supplies the 32-bit data. 
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Immediate addressing relies on 3 bits of operand, plus an optional 8 bits at PC+1 to determine an 8- 
bit base value. Bits 0 to 1 of the opcode byte determine whether the base value comes from the 
opcode byte itself, or from PC+1 , as shown in Table 356. 
Table 356. Selection for base value in immediate mode 



Opcode^ 


Base value 


00 


00000000 


01 


00000001 


10 


From PC+1 (i.e. MIUData 7 -o) 


11 


11111111 



The base value is computed by using CMDo as bit 0, and copying CMDi into the upper 7 bits. 
The resultant 8 bit base value is then used as a 32-bit value, with 0s in the upper 24 bits, or the 8-bit 
value is replicated into the upper 32 bits. The selection is determined by bit 2 of the opcode byte, as 
10 follows: 

Table 357. Replicate bits selection 



Opcode 2 


Data 


0 


No replication. Data has 0 in upper 24 bits and baseVal in lower 8 bits 


1 


Replicated. Data is 32-bit value formed by replicating baseVal. 



Opcodes that support immediate addressing are LD, ADD, XOR, AND, OR. The SC and LIA 
1 5 instructions are also immediate in that they store the data with the opcode, but they are not in the 

same form as that described here. See the detail on the individual instructions for more information. 
Single byte examples include: 

LD 0 

ADD 1 

20 • ADD OxFF... # this subtracts 1 from the acc 

XOR OxFF... # this performs an effective logical NOT operation 
Double byte examples include: 
LD 0x05 # a constant 
AND OxOF # isolates the lower nybble 
25 • LD 0x36... # useful for HMAC processing 
9.2.2 Accumulator indirect 

In this form of addressing, the Accumulator holds the effective address. 
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Opcodes that support Accumulator indirect addressing are JPI, JSI and ERA. In the case of JPI and 
JSI, the Accumulator holds the address to jump to. In the case of ERA, the Accumulator holds the 
address of the page in flash memory to be erased. 
Examples include: 
5 • JPI 
JSI 
ERA 

9.2.3 Indirect fixed 

In this form of addressing, address register AO is used as a base address, and then a specific fixed 
1 0 offset is added to the base address to give the effective address. 

Bits 2-0 of the opcode byte specify the fixed offset from AO, which means the fixed offset has a 
range of 0 to 7. 

Opcodes that support indirect indexed addressing are LD, ST, ADD, XOR, AND, OR. 
Examples include: 
15 • LD (AO), 2 

• ADD (AO), 3 

• AND (AO), 4 

• ST (AO), 7 

9.2.4 Indirect indexed 

20 In this form of addressing, an address register is used as a base address, and then an index 
register is used to offset from that base address to give the effective address. 
The address register is one of 4, and is selected via bits 2-1 of the opcode byte as follows: 
Table 358. Address register selection 



Opcode 2 -i 


address register 
selected 


00 


AO 


01 


A1 


10 


A2 


11 


A3 



25 

Bit 0 of the opcode byte selects whether index register C1 or C2 is used: 
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The counter is selected as follows: 

Table 359. Interpretation of counter for DBR 



Opcode 0 


interpretion 


0 


C1 


1 


C2 



5 Opcodes that support indirect indexed addressing are LD, ST, ADD, XOR. 

Examples include: 

• LD (A2), C1 

• ADD (A1), C1 

• ST(A3),C2 

1 0 Since C1 and C2 can only decement, processing of data structures typically works by loading Cn 
with some number n and decrementing to 0. Thus (Ax),n is the first word accessed, and (Ax),0 is the 
last 32-bit word accessed in the loop. 
9.3 ADD - Add To Accumulator 
Mnemonic: ADD 

15 Opcode: lOlOxxxx, and lllOlxxx 

Usage: ADD effective-address, or ADD immediate-value 
The ADD instruction adds the specified 32-bit value to the Accumulator via modulo 2 32 addition. 
The lllOlxxx form of the opcode follows the immediate addressing rules (see Section 9.2.1 on 
page 946). The lOlOxxxx form of the opcode defines an effective address as follows: 

20 Table 360. Interpretation of operand for ADD (1010xxxx) 



bit 3 


interpretion 


comment 


0 


(AO), offset 


indirect fixed addressing (see Section 9.2.3 on page 
948) 


1 


(An), Cn 


indirect indexed addressing (see Section 9.2.4 on 
page 948) 



The Z flag is also set during this operation, depending on whether the result (loaded 
into the Accumulator) is zero or not. 
25 9.4 AND - Bitwise AND 

Mnemonic: AND 
Opcode: lOOOOxxx, and HOlOxxx 
Usage: AND effective-address, or AND immediate-value 
The AND instruction performs a 32-bit bitwise AND operation on the Accumulator. 
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The HOlOxxx form of the opcode follows the immediate addressing rules (see Section 9.2.1 on 
page 946). The lOOOOxxx form of the opcode follows the indirect fixed addressing rules (see 
Section 9.2.3 on page 948). 

The Z flag is also set during this operation, depending on whether the resultant 32-bit value (loaded 
5 into the Accumulator) is zero or not. 

9.5 DBR - Decrement and Branch 
Mnemonic: DBR 
Opcode: OOllxxxx 
Usage: DBR Counter, Offset 
10 This instruction provides the mechanism for building simple loops. 
The counter is selected from bit 0 of the opcode byte as follows: 
Table 361 . Interpretation of counter for DBR 



bitO 


interpretion 


0 


C1 


1 


C2 



15 If the specified counter is non-zero, then the counter is decremented and the designated offset is 
added to the current instruction address (PC for 1-byte instructions, PC+1 for 2-byte instructions). If 
the specified counter is zero, it is decremented (all bits in the counter become set) and processing 
continues at the next instruction (PC+1 or PC+2). The designated offset will typically be negative for 
use in loops. 

20 The instruction is either 1 or two bytes, as determined by bits 3-1 of the opcode byte: 

If bits 3-1 = 000, the instruction consumes 2 bytes. The 8 bits at PC+1 are treated as a signed 
number and used as the offset amount. Thus OxFF is treated as -1, and 0x01 is treated as +1. 
If bits 3-1 * 000, the instruction consumes 1 byte. Bits 3-1 are treated as a negative number 
(the sign bit is implied) and used as the offset amount. Thus 1 1 1 is treated as -1 , and 001 is 
25 treated as -7. This is useful for small loops. 

The effect is that if the branch is back 1-7 bytes (1 byte is not particularly useful), then the single 
byte form of the instruction can be used. If the branch is forward, or backward more than 7 bytes, 
then the 2-byte instruction is required. 
9.6 ERA - Erase 
30 Mnemonic: ERA 

Opcode: 01110001 
Usage: ERA 

This instruction causes an erasure of the 256-byte page of flash memory pointed to by the 
Accumulator. The Accumulator is assumed to contain an 8-bit pointer to a 128-bit (16 byte) aligned 
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structure (same structure as the address registers). The page number to be erased comes from bits 
7-4, and the lower 4 bits are ignored. 

Note that the size of the flash memory page being erased is actually 512 bytes, but in terms of data 
storage and addressing from the point of view of the CPU, there is only 256 bytes in the page. 
5 9.7 HALT - Halt CPU operation 

Mnemonic: HALT 

Opcode: 01110101 

Usage: HALT 

The HALT instruction writes a 0 to the internal GO register, thereby causing the CPU to terminate the 
1 0 currently executing program. The CPU will only be restarted with a new localld transaction from the 
Master or by a globalld plus Active Mode byte. 
9.8 JMP- Jump 

Mnemonic: JMP 
Opcode: ooooxxxx 
1 5 Usage: JMP effective-address 

The JMP instruction provides for a method of branching to a specified address. The instruction loads 
the PC with the effective address. 

The new PC is loaded as follows: bits 1 1-8 are obtained from bits 3-0 of the JMP opcode byte, and 
bits 7-0 are obtained from PC+1 . 
20 9.9 JPI - Jump Indirect 

Mnemonic: JPI 

Opcode: 01100011 

Usage: JPI 

The JPI instruction loads the PC with the lower 12 bits of the Accumulator, and sets the PCRamSel 
25 register with bit 1 5 of the Accumulator. Note that the stack is unaffected (unlike JSI). 

9.1 0 JPZ - Jump to Zero 

Mnemonic: JPZ 
Opcode: 01100010 
Usage: JPZ 

30 The JPZ instruction loads the PC and PCRamSel with 0, thereby causing a jump to address 0 in Flash 
memory. 

Programmers will not typically use the JPZ command. However the CPU executes this instruction 
whenever a new command arrives over the serial interface, so that the code entry point is known 
i.e. every time the chip receives a new command, execution begins at address 0 in flash. This does 
35 not change the status of any other internal register settings (e.g. the flash test registers). 

9.1 1 JSI - Jump Subroutine Indirect 

Mnemonic: JSI 
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Opcode: 01110011 
Usage: JSI 

The JSI instruction allows the jumping to a subroutine whose address is obtained from the 
Accumulator. The instruction pushes the current PC onto the stack, loads the PC with the lower 12 bits 
5 of the Accumulator, and sets the PCRamSel register with bit 1 5 of the Accumulator. 

The stack provides for 12 levels of execution (1 1 subroutines deep). It is the responsibility of the 
programmer to ensure that this depth is not exceeded or the deepest return value will be overwritten 
(since the stack wraps). Programs can take advantage of the fact that the stack wraps. 
9.12 JSR - Jump Subroutine 
1 0 Mnemonic: JSR 

Opcode: OOOlxxxx 
Usage: JSR effective-address 

The JSR instruction provides for the most common usage of the subroutine construct. The 
instruction pushes the current PC onto the stack, and loads the PC with the effective address. 
1 5 The new PC is loaded as follows: bits 11-8 are obtained from bits 3-0 of the JSR opcode byte, and 
bits 7-0 are obtained from PC+1 . 

The stack provides for 12 levels of execution (1 1 subroutines deep). It is the responsibility of the 
programmer to ensure that this depth is not exceeded or the return value will be overwritten (since 
the stack wraps). Programs can take advantage of the fact that the stack wraps. 
20 9.13 JSZ- Jump to Subroutine at Zero 

Mnemonic: JSZ 

Opcode: oinooio 

Usage: JSZ 

The JSZ instruction jumps to the subroutine at flash address 0 (i.e. it pushes the current PC onto the 
25 stack, and loads the PC and PCRamSel with 0). 

Programmers will not typically use the JSZ command. It exists merely as a result of opcode 
decoding minimization and can be used to assist with the testing of the chip. 
9.14 LD - Load Accumulator 
Mnemonic: LD 
30 Opcode: lOllxxxx, and llllOxxx 

Usage: LD effective-address, or LD immediate-value 

The LD instruction loads the Accumulator with the 32-bit value. 

The llllOxxx form of the opcode follows the immediate addressing rules (see Section 9.2.1 on 
page 946). The lOllxxxx form of the opcode defines an effective address as follows: 

35 
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Table 362. Interpretation of operand for LD (101 1xxxx) 



bit 3 


interpretion 


comment 


0 


(AO), offset 


indirect fixed addressing (see Section 9.2.3 on page 
948) 


1 


(An), Cn 


indirect indexed addressing (see Section 9.2.4 on 
page 948) 



The Z flag is also set during this operation, depending on whether the value loaded into the 

Accumulator is zero or not. 

9.15 LIA - Load Immediate Address 

Mnemonic: LIA 

Opcode: Oiliixxx 

Usage: LIAF AddressRegister, Value # for flash addresses 

LIAR AddressRegister, Value # for ram addresses 
The LIA instruction transfers the data from PC+1 into the designated address register (A0-A3), and 
sets the memory mode bit for that address register. 
Bit 0 specifies whether the address is in flash or ram, as follows: 
Table 363. Interpretation of memory mode for LIA 



bitO 


interpretion 


0 


Flash 


1 


Ram 



The address register to be targetted is selected via bits 2-1 of the instruction. 
9.16 OR -Bitwise OR 

Mnemonic: OR 

Opcode: lOOOlxxx, and HOllxxx 

Usage: OR effective-address, or OR immediate-value 

The OR instruction performs a 32-bit bitwise OR operation on the Accumulator. 
The HOllxxx form of the opcode follows the immediate addressing rules (see Section 9.2.1 on 
page 946). The lOOOlxxx form of the opcode follows the indirect fixed addressing rules (see 
Section 9.2.3 on page 948). 

The Z flag is also set during this operation, depending on whether the resultant 32-bit value (loaded 
into the Accumulator) is zero or not. 
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9.1 7 RIA - Rotate In Address 
Mnemonic: RIA 
Opcode: lllllxxx 

Usage: RIAF AddressRegister # for flash addresses 

RIAR AddressRegister # for ram addresses 
The RIA instruction transfers the lower 8 bits of the Accumulator into the designated address register 
(A0-A3), sets the memory mode bit for that address register, and rotates the Accumulator right by 8 
bits. 

Bit 0 specifies whether the address is in flash or ram, as follows: 
Table 364. Interpretation of memory mode for RIA 



bitO 


interpretion 


0 


Flash 


l 


Ram 



The address register to be targetted is selected via bits 2-1 of the instruction. 
9.18 ROR - Rotate Right 

Mnemonic: ROR 

Opcode: llOOxxxx 

Usage: ROR Value 

The ROR instruction provides a way of rotating the Accumulator right a set number of bits. The bit(s) 
coming in at the top of the Accumulator (to become bit 31) can either come from the previous lower 
bits of the Accumulator, from the serial connection, or from external flags. The bit(s) rotated out can 
also be output from the serial connection, or combined with an external flag. 
The allowed operands are as follows: 

Table 365. Interpretation of operand for ROR 



bits 3-0 


interpretion 


0000 


RB 


0001 


XRB 


0010 


WriteMask 


0011 


1 


0100 


- (reserved) 


0101 


3 


0110 


31 


0111 


24 
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1000 


C1 


1001 


C2 


1010 


- (reserved) 


i m i 
1U11 


- (reserved) 


1100 


8 


1101 


ID 


1110 


InByte 


1111 


OutByte 



The Z flag is also set during this operation, depending on whether resultant 32-bit value (loaded 

into the Accumulator) is zero or not. 
In its simplest form, the operand for the ROR instruction is one of 1, 3, 8, 24, 31, indicating how many 
5 bit positions the Accumulator should be rotated. For these operands, there is no external input or 

output - the bits of the Accumulator are merely rotated right. Note that these values are the equivalent 
to rotating left 31, 29, 24, 8, 1 bit positions. 

With operand WriteMask, the lower 8 bits of the Accumulator are transferred to the WriteMask register, 
and the Accumulator is rotated right by 1 bit. This conveniently allows successive nybbles to be 
1 0 masked during Flash writes if the Accumulator has been preloaded with an appropriate value (eg 
0x01). 

With operands C1 and C2, the lower appropriate number of bits of the Accumulator (3 for C1, 6 for C2) 
are transferred to the C1 or C2 register and the lower 6 bits of the Accumulator are loaded with the 
previous value of the Cn register. The remaining upper bits of the Accumulator are set as follows: bit 
1 5 31-24 are copied from previous bits 7-0, and bits 23-6 are copied from previous bits 31-14 

(effectively junk). As a result, the Accumulator should be subsequently masked if the programmer 
wants to compare for specific values). 

With operand ID, the 7 low-order bits are transferred from the Accumulator to the Localld register, the 
low-order 8 bits of the Accumulator are copied to the Trim register if the Trim register has not already 

20 been written to after power-on reset, and the Accumulator is rotated right by 8 bits. This means that 
the ROR ID instruction needs to be performed twice, typically during Global Active Mode - once to 
set Trim, and once to set Localld. Note there is no way to read the contents of the localld or Trim 
registers directly. However the Localld sent to the program for a command is available as bits 7-1 of 
the first byte obtained from InByte after program startup. 

25 With operand InByte, the next serial input byte is transferred to the highest 8 bits of the Accumulator. 
The InByteValid bit is also cleared. If there is no input byte available from the client yet, execution is 
suspended until there is one. The remainder of the Accumulator is shifted right 8 bit positions (bit31 
becomes bit 23 etc.), with lowest bits of the Accumulator shifted out. 
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With operand OutByte, the Accumulator is shifted right 8 bit positions. The byte shifted out from bits 7-0 
is stored in the OutByte register and the OutByteValid flag is set. It is therefore ready for a client to 
read. If the OutByteValid flag is already set, execution of the instruction stalls until the OutByteValid flag 
cleared (when the OutByte byte has been read by the client). The new data shifted in to the upper 8 
5 bits of the Accumulator is what was transferred to the OutByte register (i.e. from the Accumulator). 

Finally, the RB and XRB operands allow the implementation of LFSRs and multiple precision shift 
registers. With RB, the bit shifted out (formally bit 0) is written to the RTMP register. The register 
currently in the RTMP register becomes the new bit 31 of the Accumulator. Performing multiple ROR RB 
commands over several 32-bit values implements a multiple precision rotate/shift right. The XRB 

1 0 operates in the same way as RB, in that the current value in the RTMP register becomes the new bit 
31 of the Accumulator. However with the XRB instruction, the bit formally known as bit 0 does not 
simply replace RTMP (as in the RB instruction). Instead, it is XORed with RTMP, and the result stored 
in RTMP. This allows the implementation of long LFSRs, as required by the authentication protocol. 
9.1 9 RTS - Return From Subroutine 

1 5 Mnemonic: RTS 

Opcode: omoioo 
Usage: RTS 

The RTS instruction pulls the saved PC from the stack, adds 1 , and resumes execution at the 
resultant address. The effect is to cause execution to resume at the instruction after the most 
20 recently executed JSR or JSI instruction. 

Although 12 levels of execution are provided for (1 1 subroutines), it is the responsibility of the 
programmer to balance each JSR and JSI instruction with an RTS. A RTS executed with no previous 
JSR will cause execution to begin at whatever address happens to be pulled from the stack. Of 
course this may be desired behaviour in specific circumstances. 
25 9.20 SC - Set Counter 

Mnemonic: SC 
Opcode: OlOOxxxx 
Usage: SC Counter Value 

The SC instruction is used to transfer a 3-bit Value into the specified counter. The operand 
30 determines which of counters C1 and C2 is to be loaded as well as the value to be loaded. Value is 
stored in bits 3-1 of the 8-bit opcode, and the counter is specified by bit 0 as follows: 
Table 366. Interpretation of counter for SC 



bitO 


interpretion 


0 


C1 


1 


C2 
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Since counter C1 is 3 bits, Value is copied directly into C1. 

For counter C2, C224 are copied to C2s-3, and Value is copied to C22-0. Two SC C2 instructions are 
therefore required to load C2 with a given 6-bit value. For example, to load C2 with OxOC, we would 
have SC C2 1 followed by SC C2 4. 
5 9.21 ST - Store Accumulator 
Mnemonic: ST 
Opcode: OlOlxxxx 
Usage: ST effective-address 

The ST instruction stores the 32-bit Accumulator at the effective address. The effective address is 
1 0 determined as follows: 

Table 367. Interpretation of operand for ST (0101xxxx) 



bit 3 


interpretion 


comment 


0 


(AO), offset 


indirect fixed addressing (see Section 9.2.3 on page 
948) 


1 


(An), Cn 


indirect indexed addressing (see Section 9.2.4 on 
page 948) 



If the effective address in Flash memory, only those nybbles whose corresponding WriteMask bit is 
1 5 set will be written to Flash. Programmers should be very aware of flash characteristics (write time, 
longevity, page size etc. when storing data in flash). 

There is always the possibility that power could be removed during a write to Flash. If this occurs, 
the flash will be in an indeterminate state. If the QA Chip is warned by the external system that 
power is about to be removed (via the master causing a transition to Idle Mode), the write will be 
20 aborted cleanly at the nearest nybble boundary (writes occur in the order of least significant to most 
significant). 

9.22 TBR - Test and Branch 

Mnemonic: TBR 
Opcode: OOlOxxxx 
25 Usage: TBR Value Offset 

The Test and Branch instruction tests the status of the Z flag (the zero-ness of the Accumulator), and 
then branches if a match ocurs. 

The zero-ness is selected from bit 0 of the opcode byte as follows: 
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Table 368. Interpretation of zero-ness for TBR 



bitO 


interpretion 


0 


true if Acc is zero (Z = 1 ) 


1 


true if Acc is non-zero (Z=0) 



If the specified zero-test matches, then the designated offset is added to the current instruction 
5 address (PC for 1-byte instructions, PC+1 for 2-byte instructions). If the zero-test does not match, 
processing continues at the next instruction (PC+1 or PC+2). The instruction is either 1 or two bytes, 
as determined by bits 3-1 of the opcode byte: 

If bits 3-1 = 000, the instruction consumes 2 bytes. The 8 bits at PC+1 are treated as a signed 
number and used as the offset amount to be added to PC+1. Thus OxFF is treated as -1, and 
10 0x01 is treated as +1. 

If bits 3-1 * 000, the instruction consumes 1 byte. Bits 3-1 are treated as a positive number 
(the sign bit is implied) and used as the offset amount to be added to PC. Thus 1 1 1 is treated 
as 7, and 001 is treated as 1 . This is useful for skipping over a small number of instructions. 
The effect is that if the branch is forward 1-7 bytes (1 byte is not particularly useful), then the single 
1 5 byte form of the instruction can be used. If the branch is backward, or forward more than 7 bytes, 
then the 2-byte instruction is required. 
9.23 XOR - Bitwise Exclusive OR 
Mnemonic: XOR 

Opcode: lOOlxxxx, and lllOOxxx 

20 Usage: XOR effective-address, or XOR immediate-value 

The XOR instruction performs a 32-bit bitwise XOR operation on the Accumulator. 
The lllOOxxx form of the opcode follows the immediate addressing rules (see Section 9.2.1 on 
page 946). The lOOlxxxx form of the opcode has an effective address as follows: 

Table 369. Interpretation of operand for XOR (1001xxxx) 

25 



bit 3 


interpretion 


comment 


0 


(AO), offset 


indirect fixed addressing (see Section 9.2.3 on page 948) 


1 


(An), Cn 


indirect indexed addressing (see Section 9.2.4 on page 
948) 



The Z flag is also set during this operation, depending on whether the result (loaded into the 
Accumulator) is zero or not. 
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Implementation 
10 Introduction 

This chapter provides the high-level definition of a CPU capable of implementing the functionality 

required of an QA Chip. 

10.1 Physical Interface 

10.1.1 Pin connections 

The pin connections are described in Table 370. 

Table 370. Pin connections to QA Chip 



pin 


direction 


description 


Vdd 


In 


Nominal voltage. If the voltage deviates from this by 
more than a fixed amount, the chip will RESET. 


GND 


In 




SCIk 


In 


Serial clock 


SDa 


In/Out 


Serial data 



The system operating clock SysClk is different to SCIk. SysClk is derived from an internal ring oscillator 
based on the process technology. In the FPGA implementation SysClk is obtained via a 5th pin. 
10.1.2 Size and cost 

The QA Chip uses a 0.25 urn CMOS Flash process for an area of 1mm 2 yielding a 10 cent 
manufacturing cost in 2002. A breakdown of area is listed in Table 371 . 

Table 371 . Breakdown of Area for QA Chip 



approximate area 
(mm 2 ) 


description 


0.49 


8KByte flash memory 

TSMC: SFC0008_08B9_HE 

(8K x 8-bits, erase page size = 512 bytes) 

Area = 724.688nm x 682.05 |im. 


0.08 


3072 bits of static RAM 


0.38 


General logic 


0.05 


Analog circuitry 


1 


TOTAL (approximate) 



Note that there is no specific test circuitry (scan chains or BIST) within the QA Chip (see Section 
10.3.10 on page 965), so the total transistor count is as shown in Table 371 . 
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10.1.3 Reset 

The chip performs a RESET upon power-up. In addition, tamper detection and prevention circuitry 
in the chip will cause the chip to either RESET or erase Flash memory (depending on the attack 
detected) if an attack is detected. 
5 10.2 Operating speed 

The base operating system clock SysClk is generated internally from a ring oscillator (process 
dependant). Since the frequency varies with operating temperature and voltage, the clock is passed 
through a temperature-based clock filter before use (see Section 10.3.3 on page 961). The 
frequency is built into the chip during manufacture, and cannot be changed. The frequency is in the 
10 range 7-14 MHz. 

1 0.3 General manufacturing comments 

Manufacturing comments are not normally made when normally describing the architecture of a 
chip. However, in the case of the QA Chip, the physical implementation of the chip is very much tied 
:o the security of the key. Consequently a number of specialized circuits and components are 
1 5 necessary for implementation of the QA Chip. They are listed here. 
Flash process 
Internal randomized clock 
Temperature based clock filter 
Noise generator 
20 • Tamper Prevention and Detection circuitry 
Protected memory with tamper detection 
Boot-strap circuitry for loading program code 
Data connections in polysilicon layers where possible 
OverUnderPower Detection Unit 
25 • No scan-chains or BIST 
0.3.1 Flash process 

The QA Chip is implemented with a standard Flash manufacturing process. It is important that a 
Flash process be used to ensure that good endurance is achieved (parts of the Flash memory can 
be erased/written many times). 

30 10.3.2 Internal randomized clock 

To prevent clock glitching and external clock-based attacks, the operating clock of the chip should 
be generated internally. This can be conveniently accomplished by an internal ring oscillator. The 
length of the ring depends on the process used for manufacturing the chip. 
Due to process and temperature variations, the clock needs to be trimmed to bring it into a range 

35 usable for timing of Flash memory writes and erases. 

The internal clock should also contain a small amount of randomization to prevent attacks where 
light emissions from switching events are captured, as described below. 
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Finally, the generated clock must be passed through a temperature-based clock filter before being 
used by the rest of the chip (see Section 10.3.3 on page 961). 

The normal situation for FET implementation for the case of a CMOS inverter (which involves a 
pMOS transistor combined with an nMOS transistor) as shown in Figure 353. 
5 During the transition, there is a small period of time where both the nMOS transistor and the pMOS 
transistor have an intermediate resistance. The resultant power-ground short circuit causes a 
temporary increase in the current, and in fact accounts for around 20% of current consumed by a 
CMOS device. A small amount of infrared light is emitted during the short circuit, and can be viewed 
through the silicon substrate (silicon is transparent to infrared light). A small amount of light is also 
10 emitted during the charging and discharging of the transistor gate capacitance and transmission line 
capacitance. 

For circuitry that manipulates secret key information, such information must be kept hidden. 
Fortunately, IBM's PICA system and LVP (laser voltage probe) both have a requirement for 
repeatability due to the fact that the photo emissions are extremely weak (one photon requires more 
1 5 than 10 5 switching events). PICA requires around 10 9 pases to build a picture of the optical 
waveform. Similarly the LVP requires multiple passes to ensure an adequate SNR. 
Randomizing the clock stops repeatability (from the point of view of collecting information about the 
same position in time), and therefore reduces the possibility of this attack. 

1 0.3.3 Temperature based clock filter 

20 The QA Chip circuitry is designed to operate within a specific clock speed range. Although the clock 
is generated by an internal ring oscillator, the speed varies with temperature and power. Since the 
user supplies the temperature and power, it is possible for an attacker to attempt to introduce race- 
conditions in the circuitry at specific times during processing. An example of this is where a low 
temperature causes a clock speed higher than the circuitry is designed for, and this may prevent an 

25 XOR from working properly, and of the two inputs, the first may always be returned. These styles of 
transient fault attacks are documented further in [1]. The lesson to be learned from this is that the 
input power and operating temperature cannot be trusted. 

Since the chip contains a specific power filter, we must also filter the clock. This can be achieved 
with a temperature sensor that allows the clock pulses through only when the temperature range is 
30 such that the chip can function correctly. 

The filtered clock signal would be further divided internally as required. 

1 0.3.4 Noise Generator 

Each QA Chip should contain a noise generator that generates continuous circuit noise. The noise 
will interfere with other electromagnetic emissions from the chip's regular activities and add noise to 
35 the l dd signal. Placement of the noise generator is not an issue on an QA Chip due to the length of 
the emission wavelengths. 
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The noise generator is used to generate electronic noise, multiple state changes each clock cycle, 
and as a source of pseudo-random bits for the Tamper Prevention and Detection circuitry (see 
Section 10.3.5 on page 962). 

A simple implementation of a noise generator is a 64-bit maximal period LFSR seeded with a non- 
zero number. 

10.3.5 Tamper Prevention and Detection circuitry 

A set of circuits is required to test for and prevent physical attacks on the OA Chip. However what is 
actually detected as an attack may not be an intentional physical attack. It is therefore important to 
distinguish between these two types of attacks in an QA Chip: 

where you can be certain that a physical attack has occurred. 

where you cannot be certain that a physical attack has occurred. 
The two types of detection differ in what is performed as a result of the detection. In the first case, 
where the circuitry can be certain that a true physical attack has occurred, erasure of flash memory 
key information is a sensible action. In the second case, where the circuitry cannot be sure if an 
attack has occurred, there is still certainly something wrong. Action must be taken, but the action 
should not be the erasure of secret key information. A suitable action to take in the second case is a 
chip RESET. If what was detected was an attack that has permanently damaged the chip, the same 
conditions will occur next time and the chip will RESET again. If, on the other hand, what was 
detected was part of the normal operating environment of the chip, a RESET will not harm the key. 
A good example of an event that circuitry cannot have knowledge about, is a power glitch. The 
glitch may be an intentional attack, attempting to reveal information about the key. It may, however, 
be the result of a faulty connection, or simply the start of a power-down sequence. It is therefore 
best to only RESET the chip, and not erase the key. If the chip was powering down, nothing is lost. 
If the System is faulty, repeated RESETs will cause the consumer to get the System repaired. In 
both cases the consumable is still intact. 

A good example of an event that circuitry can have knowledge about, is the cutting of a data line 
within the chip. If this attack is somehow detected, it could only be a result of a faulty chip 
(manufacturing defect) or an attack. In either case, the erasure of the secret information is a 
sensible step to take. 

Consequently each QA Chip should have 2 Tamper Detection Lines - one for definite attacks, and 
one for possible attacks. Connected to these Tamper Detection Lines would be a number of 
Tamper Detection test units, each testing for different forms of tampering. In addition, we want to 
ensure that the Tamper Detection Lines and Circuits themselves cannot also be tampered with. 
At one end of the Tamper Detection Line is a source of pseudo-random bits (clocking at high speed 
compared to the general operating circuitry). The Noise Generator circuit described above is an 
adequate source. The generated bits pass through two different paths - one carries the original 
data, and the other carries the inverse of the data. The wires carrying these bits are in the layer 
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above the general chip circuitry (for example, the memory, the key manipulation circuitry etc.). The 
wires must also cover the random bit generator. The bits are recombined at a number of places via 
an XOR gate. If the bits are different (they should be), a 1 is output, and used by the particular unit 
(for example, each output bit from a memory read should be ANDed with this bit value). The lines 
5 finally come together at the Flash memory Erase circuit, where a complete erasure is triggered by a 
0 from the XOR. Attached to the line is a number of triggers, each detecting a physical attack on the 
chip. Each trigger has an oversize nMOS transistor attached to GND. The Tamper Detection Line 
physically goes through this nMOS transistor. If the test fails, the trigger causes the Tamper Detect 
Line to become 0. The XOR test will therefore fail on either this clock cycle or the next one (on 
1 0 average), thus RESETing or erasing the chip. 

Figure 349 illustrates the basic principle of a Tamper Detection Line in terms of tests and the XOR 
connected to either the Erase or RESET circuitry. 

The Tamper Detection Line must go through the drain of an output transistor for each test, as 
illustrated by Figure 350. 

15 It is not possible to break the Tamper Detect Line since this would stop the flow of 1s and 0s from 
the random source. The XOR tests would therefore fail. As the Tamper Detect Line physically 
passes through each test, it is not possible to eliminate any particular test without breaking the 
Tamper Detect Line. 

It is important that the XORs take values from a variety of places along the Tamper Detect Lines in 
20 order to reduce the chances of an attack. Figure 351 illustrates the taking of multiple XORs from the 

Tamper Detect Line to be used in the different parts of the chip. Each of these XORs can be 

considered to be generating a ChipOK bit that can be used within each unit or sub-unit. 

A typical usage would be to have an OK bit in each unit that is ANDed with a given ChipOK bit each 

cycle. The OK bit is loaded with 1 on a RESET. If OK is 0, that unit will fail until the next RESET. If 
25 the Tamper Detect Line is functioning correctly, the chip will either RESET or erase all key 

information. If the RESET or erase circuitry has been destroyed, then this unit will not function, thus 

thwarting an attacker. 

The destination of the RESET and Erase line and associated circuitry is very context sensitive. It 
needs to be protected in much the same way as the individual tamper tests. There is no point 
30 generating a RESET pulse if the attacker can simply cut the wire leading to the RESET circuitry. 
The actual implementation will depend very much on what is to be cleared at RESET, arid how 
those items are cleared. 

Finally, Figure 352 shows how the Tamper Lines cover the noise generator circuitry of the chip. The 
generator and NOT gate are on one level, while the Tamper Detect Lines run on a level above the 
35 generator. 
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1 0.3.6 Protected memory with tamper detection 

It is not enough to simply store secret information or program code in flash memory. The Flash 
memory and RAM must be protected from an attacker who would attempt to modify (or set) a 
particular bit of program code or key information. The mechanism used must conform to being used 
5 in the Tamper Detection Circuitry (described above). 

The first part of the solution is to ensure that the Tamper Detection Line passes directly above each 
flash or RAM bit. This ensures that an attacker cannot probe the contents of flash or RAM. A breach 
of the covering wire is a break in the Tamper Detection Line. The breach causes the Erase signal to 
be set, thus deleting any contents of the memory. The high frequency noise on the Tamper 

1 0 Detection Line also obscures passive observation. 

The second part of the solution for flash is to always store the data with its inverse. In each byte, 4 
bits contains the data, and 4 bits (the shadow) contains the inverse of the data. If both are 0, this is 
a valid erase state, and the value is 0. Otherwise, the memory is only valid if the 4 bits of shadow 
are the inverse of the main 4 bits. The reasoning is that it is possible to add electrons to flash via a 

1 5 FIB, but not take electrons away. If it is possible to change a 0 to 1 for example, it is not possible to 
do the same to its inverse, and therefore regardless of the sense of flash, an attack can be 
detected. 

The second part of the solution for RAM is to use a parity bit. The data part of the register can be 

checked against the parity bit (which will not match after an attack). 
20 The bits coming from Flash and RAM can therefore be validated by a number of test units (one per 

bit) connected to the common Tamper Detection Line. The Tamper Detection circuitry would be the 

first circuitry the data passes through (thus stopping an attacker from cutting the data lines). 

In addition, the data and program code should be stored in different locations for each chip, so an 

attacker does not know where to launch an attack. Finally, XORing the data coming in and going to 
25 Flash with a random number that varies for each chip means that the attacker cannot learn anything 

about the key by setting or clearing an individual bit that has a probability of being the key (the 

inverse of the key must also be stored somewhere in flash). 

Finally, each time the chip is called, every flash location is read before performing any program 
code. This allows the flash tamper detection to be activated in a common spot instead of when the 
30 data is actually used or program code executed. This reduces the ability of an attacker to know 
exactly what was written to. 

10.3.7 Boot-strap circuitry for loading program code 

Program code should be kept in protected flash instead of ROM, since ROM is subject to being 
altered in a non-testable way. A boot-strap mechanism is therefore required to load the program 
35 code into flash memory (flash memory is in an indeterminate state after manufacture). 

The boot-strap circuitry must not be in a ROM - a small state-machine suffices. Otherwise the boot 
code could be trivially modified in an undetectable way. 
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The boot-strap circuitry must erase all flash memory, check to ensure the erasure worked, and then 
load the program code. 

The program code should only be executed once the flash program memory has been validated via 
Program Mode. 

5 Once the final program has been loaded, a fuse can be blown to prevent further programming of the 
chip. 

10.3.8 Connections in polysilicon layers where possible 

Wherever possible, the connections along which the key or secret data flows, should be made in 
the polysilicon layers. Where necessary, they can be in metal 1, but must never be in the top metal 
1 0 layer (containing the Tamper Detection Lines). 

10.3.9 OverUnder Power Detection Unit 

Each QA Chip requires an OverUnder Power Detection Unit (PDU) to prevent Power Supply 
Attacks. A PDU detects power glitches and tests the power level against a Voltage Reference to 
ensure it is within a certain tolerance. The Unit contains a single Voltage Reference and two 
1 5 comparators. The PDU would be connected into the RESET Tamper Detection Line, thus causing a 
RESET when triggered. 

A side effect of the PDU is that as the voltage drops during a power-down, a RESET is triggered, 
thus erasing any work registers. 

10.3.10 No scan chains or BIST 

20 Test hardware on an QA Chip could very easily introduce vulnerabilities. In addition, due to the 

small size of the QA Chip logic, test hardware such as scan paths and BIST units could in fact take 
a sizeable chunk of the final chip, lowering yield and causing a situation where an error in the test 
hardware causes the chip to be unusable. As a result, the QA Chip should not contain any BIST or 
scan paths. Instead, the program memory must first be validated via the Program Mode 

25 mechanism, and then a series of program tests run to verify the remaining parts of the chip. 
11 Architecture 

Figure 389 shows a high level block diagram of the QA Chip. Note that the tamper prevention and 
detection circuitry is not shown. 
11.1 Analogue unit 

30 Figure 390 shows a block diagram of the Analogue Unit. Blocks shown in yellow provide additional 
protection against physical and electrical attack and, depending on the level of security required, 
may optionally be implemented. 
11.1.1 Ring oscillator 

The operating clock of the chip (SysClk) is generated by an internal ring oscillator whose frequency 
35 can be trimmed to reduce the variation from 4:1 (due to process and temperature) down to 2:1 
(temperature variations only) in order to satisfy the timing requirements of the Flash memory. 
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The length of the ring depends on the process used for manufacturing the chip. A nominal operating 
frequency range of 10 MHz is sufficient. This clock should contain a small amount of randomization 
to prevent attacks where light emissions from switching events are captured. 
Note that this is different to the input SCIk which is the serial clock for external communication. 
5 The ring oscillator is covered by both Tamper Detection and Prevention lines so that if an attacker 
attempts to tamper with the unit, the chip will either RESET or erase all secret information. 
FPGA Note: the FPGA does not have an internal ring oscillator. An additional pin (SysClk) is used 
instead. This is replaced by an internal ring oscillator in the final ASIC. 

1 1 .1 .2 Voltage reference 

1 0 The voltage reference block maintains an output which is substantially independant of process, 
supply voltage and temperature. It provides a reference voltage which is used by the PDU and a 
reference current to stabilise the ring oscillator. It may also be used as part of the temperature 
based clock filter described in Section 10.3.3 on page 961 . 

1 1 .1 .3 OverUnder power detection unit 

1 5 The OverUnder Power Detection Unit (PDU) is the same as that described in Section 10.3.9 on 
page 965. 

The Under Voltage Detection Unit provides the signal PwrFailing which, if asserted, indicates that 
the power supply may be turning off. This signal is used to rapidly terminate any Flash write that 
may be in progress to avoid accidentally writing to an indeterminate memory location. 
20 Note that the PDU triggers the RESET Tamper Detection Line only. It does not trigger the Erase 
Tamper Detection Line. 

The PDU can be implemented with regular CMOS, since the key does not pass through this unit. It 
does not have to be implemented with non-flashing CMOS. 

The PDU is covered by both Tamper Detection and Prevention lines so that if an attacker attempts 
25 to tamper with the unit, the chip will either RESET or erase all secret information. 

1 1 .1 .4 Power-on Reset and Tamper Detect Unit 

The Power-on Reset unit (POR) detects a power-on condition and generates the PORstL signal that 
is fed to all the validation units, including the two inside the Tamper Detect Unit (TDU). 
All other logic is connected to RstL, which is the PORstL gated by the VAL unit attached to the Reset 
30 tamper detection lines (see Section 10.3.5 on page 962) within the TDU. Therefore, if the Reset 

tamper line is asserted, the validation will drive RstL low, and can only be cleared by a power-down. 
If the tamper line is not asserted, then RstL = PORstL. 

The TDU contains a second VAL unit attached to the Erase tamper detection lines (see Section 

10.3.5 on page 962) within the TDU. It produces a TamperEraseOK signal that is output to the MIU (1 
35 = the tamper lines are all OK, 0 = force an erasure of Flash). 
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1 1 .1 .5 Noise generator 

The Noise Generator (NG) is the same as that described in Section 10.3.4 on page 961 . It is based 
on a 64-bit maximal period LFSR loaded with a set non-zero bit pattern on RESET. 
The NG must be protected by both Tamper Detection and Prevention lines so that if an attacker 
5 attempts to tamper with the unit, the chip will either RESET or erase all secret information. 

In addition, the bits in the LFSR must be validated to ensure they have not been tampered with (i.e. 
a parity check). If the parity check fails, the Erase Tamper Detection Line is triggered. 
Finally, all 64 bits of the NG are ORed into a single bit. If this bit is 0, the Erase Tamper Detection 
Line is triggered. This is because 0 is an invalid state for an LFSR. 

10 11.2 Trim Unit 

The 8-bit Trim register within the Trim Unit has a reset value of 0x00 (to enable the flash reads to 
succeed even in the fastest process corners), and is written to either by the PMU during Trim Mode 
or by the CPU in Active Mode. Note that the CPU is only able to write once to the Trim register 
between power-on-reset due to the TrimDone flag which provides overloading of LocalldWE. 

1 5 The reset value of Trim (0) means that the chip has a nominal frequency of 2.7MHz - 1 0MHz. The 
upper of the range is when we cannot trim it lower than this (or we could allow some spread on the 
acceptable trimmed frequency but this will reduce our tolerance to ageing, voltage and temperature 
which is the range 7MHz to 14MHz). The 2.7MHz value is determined by a chip whose oscillator 
runs at 10MHz when the trim register is set to its maximum value, so then it must run at 2.7MHz 

20 when trim = 0. This is based on the non-linear frequency-current characteristic of the oscillator. 
Chips found outside of these limits will be rejected. 

The frequency of the ring oscillator is measured by counting cycles 6 , in the PMU, over the byte 
period of the serial interface. The frequency of the serial clock, SCIk, and therefore the byte period 
will be accurately controlled during the measurement. The cycle count (Fmeas) at the end of the 
25 period is read over the serial bus and the Trim register updated (Trimval) from its power on default 
(POD) value. The steps are shown in Figure 391. Multiple measure - read - trim cycles are possible 
to improve the accuracy of the trim procedure. 

A single byte for both Fmeas and Trimval provide sufficient accuracy for measurement and trimming 
of the frequency. If the bus operates at 400kHz, a byte (8 bits) can be sent in 20jis. By dividing the 
30 maximum oscillator frequency, expected to be 20MHz, by 2 results in a cycle count of 200 and 50 
for the minimum frequency of 5MHz resulting in a worst case accuracy of 2%. 
Figure 392 shows a block diagram of the Trim Unit: 



6 Note that the PMU counts using 12-bits, saturates at OxFFF, and returns the cycle count divided by 2 as an 8- 
bit value. This means that multiple measure-read-trim cycles may be necessary to resolve any amibguity. In 
any case, multiple cycles are necessary to test the correctness of the trim circuitry during manufacture test. 
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The 8-bit Trim value is used in the analog Trim Block to adjust the frequency of the ring oscillator by 
controlling its bias current. The two Isbs are used as a voltage trim, and the 6 msbs are used as a 
frequency trim. 

The analog Trim Clock circuit also contains a Temperature filter as described in Section 10.3.3 on 
5 page 961 . 

11.3 IOUnit 

The QA Chip acts as a slave device, accepting serial data from an external master via the IO Unit 
(IOU). Although the IOU actually transmits data over a 1-bit line, the data is always transmitted and 
received in 1-byte chunks. 

1 0 The IOU receives commands from the master to place it in a specific operating mode, which is one 
of: 

Idle Mode: is the startup mode for the IOU if the fuse has not yet been blown. Idle Mode is 
the mode where the QA Chip is waiting for the next command from the master. Input signals 
from the CPU are ignored. 
1 5 • Program Mode: is where the QA Chip erases all currently stored data in the Flash memory 
(program and secret key information) and then allows new data to be written to the Flash. 
The IOU stays in Program Mode until told to enter another mode. 

Active Mode: is the startup mode for the IOU if the fuse has been blown (the program is safe 
to run). Active Mode is where the QA Chip allows the program code to be executed to 
20 process the master's specific command. The IOU returns to Idle Mode automatically when 

the command has been processed, or if the time taken between consuming input bytes (while 
the master is writing the data) or generating output bytes (while the master is reading the 
results) is too great. 

Trim Mode: is where the QA Chip allows the generation and setting of a trim value to be used 
25 on the internal ring oscillator clock value. This must be done for safety reasons before a 

program can be stored in the Flash memory. 

See Section 12 on page 970 for detailed information about the IOU. 

1 1 .4 Central Processing Unit 

The Central Processing Unit (CPU) block provides the majority of the circuitry of the 4-bit 
30 microprocessor. Figure 393 shows a high level view of the block. 

1 1 .5 Memory Interface Unit 

The Memory Interface Unit (MIU) provides the interface to flash and RAM. The MIU contains a 
Program Mode Unit that allows flash memory to be loaded via the IOU, a Memory Request Unit that 
maps 8-bit and 32-bit requests into multiple byte based requests, and a Memory Access Unit that 
35 generates read/write strobes for individual accesses to the memory. 
Figure 394 shows a high level view of the MIU block. 
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1 1 .6 Memory Components 

The Memory Components block isolates the memory implementation from the rest of the QA Chip. 
The entire contents of the Memory Components block must be protected from tampering. Therefore 
the logic must be covered by both Tamper Detection Lines. This is to ensure that program code, 
5 keys, and intermediate data values cannot be changed by an attacker. The 8-bit wide RAM also 
needs to be parity-checked. 

Figure 395 shows a high level view of the Memory Components block. It consists of 8KBytes of 
flash memory and 3072 bits of parity checked RAM. 

11.6.1 RAM 

10 The RAM block is shown here as a simple 96 x 32-bit RAM (plus parity included for verification). 
The parity bit is generated during the write. 

The RAM is in an unknown state after RESET, so program code cannot rely on RAM being 0 at 
startup. 

The initial version of the ASIC has the RAM implemented by Artisan component RA1SH (96 x 32-bit 
1 5 RAM without parity). Note that the RAMOutEn port is active low i.e. when 0, the RAM is enabled, and 
when 1 , the RAM is disabled. 

1 1 .6.2 Flash memory 

A single Flash memory block is used to hold all non-volatile data. This includes program code and 
variables. The Flash memory block is implemented by TSMC component SFC0008_08B9_HE [4], 
20 which has the following characteristics: 

8K x 8-bit main memory, plus 128 x 8-bit information memory 

512 byte page erase 

Endurance of 20,000 cycles (min) 

Greater than 100 years data retention at room temperature 
25 • Access time: 20 ns (max) 

Byte write time: 20^s (min) 

Page erase time: 20ms (min) 

Device erase time: 200 ms (min) 

Area of 0.494mm 2 (724.66^im x 682.05|am) 
30 The FlashCtrl line are the various inputs on the SFC0008_08B9_HE required to read and write bytes, 
erase pages and erase the device. A total of 9 bits are required (see [4] for more information). 
Flash values are unchanged by a RESET. After manufacture, the Flash contents must be 
considered to be garbage. After an erasure, the Flash contents in the SFC0008_08B9_HE is all 1s. 

11.6.3 VAL blocks 

35 The two VAL units are validation units connected to the Tamper Prevention and Detection circuitry 
(described in Section 10.3.5 on page 962), each with an OK bit. The OK bit is set to 1 on PORstL, and 
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ORed with the ChipOK values from both Tamper Detection Lines each cycle. The OK bit is ANDed 
with each data bit that passes through the unit. 

In the case of VALi, the effective byte output from the flash will always be 0 if the chip has been 
tampered with. This will cause shadow tests to fail, program code will not execute, and the chip will 
5 hang. 

In the case of VAl_2, the effective byte from RAM will always be 0 if the chip has been tampered with, 
thus resulting in no temporary storage for use by an attacker. 
12 I/O Unit 

The I/O Unit (IOU) is responsible for providing the physical implementation of the logical interface 
1 0 described in Section 5.1 on page 933, moving between the various modes (Idle, Program, Trim and 
Active) according to commands sent by the master. 

The IOU therefore contains the circuitry for communicating externally with the external world via the 
SCIk and SDa pins. The IOU sends and receives data in 8-bit chunks. Data is sent serially, most 
significant bit (bit 7) first through to least significant bit (bit 0) last. When a master sends a command 
15 to an QA Chip, the command commences with a single byte containing an id in bits 7-1 , and a 
read/write sense in bit 0, as shown in Figure 396. 

The IOU recognizes a global id of 0x00 and a local id of Localld (set after the CPU has executed 
program code at reset or due to a global id / ActiveMode command on the serial bus). Subsequent 
bytes contain modal information in the case of global id, and command/data bytes in the case of a 

20 match with the local id. 

If the master sends data too fast, then the IOU will miss data, since the IOU never holds the bus. 
The meaning of too fast depends on what is running. In Program Mode, the master must send data 
a little slower than the time it takes to write the byte to flash (actually written as 2 x 8-bit writes, or 
40ns). In ActiveMode, the master is permitted to send and request data at rates up to 500 KHz. 

25 None of the latches in the IOU need to be parity checked since there is no advantage for an 
attacker to destroy or modify them. 

The IOU outputs 0s and inputs 0s if either of the Tamper Detection Lines is broken. This will only 
come into effect if an attacker has disabled the RESET and/or erase circuitry, since breaking either 
Tamper Detection Lines should result in a RESET or the erasure of all Flash memory. 
30 The lOU's InByte, InByteValid, OutByte, and OutByteValid registers are used for communication between 
the master and the QA Chip. InByte and InByteValid provide the means for clients to pass commands 
and data to the QA Chip. OutByte and OutByteValid provide the means for the master to read data from 
the QA Chip. 

Reads from InByte should wait until InByteValid is set. InByteValid will remain clear until the 
35 master has written the next input byte to the QA Chip. When the IOU is told (by the FEU or 

MU) that InByte has been read, the IOU clears the InByteValid bit to allow the next byte to be 
read from the client. 
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Writes to OutByte should wait until OutByteValid is clear. Writing OutByte sets the OutByteValid bit 
to signify that data is available to be transmitted to the master. OutByteValid will then remain 
set until the master has read the data from OutByte. If the master requests a byte but 
OutByteValid is clear, the IOU sends a NAck to indicate the data is not yet ready. 
When the chip is reset via RstL, the IOU enters ActiveMode to allow the PMU to run to load the fuse. 
Once the fuse has been loaded (when MIUAvail transitions from 0 to 1 ) the IOU checks to see if the 
program is known to be safe. If it is not safe, the IOU reverts to IdleMode. If it is safe (FuseBlown = 1), 
the IOU stays in ActiveMode to allow the program to load up the localld and do any other reset 
initialization, and will not process any further serial commands until the CPU has written a byte to 
the OutByte register (which may be read or not at the discretion of the master using a localld read). In 
both cases the master is then able to send commands to the QA Chip as described in Section 5.1 
on page 933. 

Figure 397 shows a block diagram of the IOU. 

With regards to InByteValid inputs, set has priority over reset, although both set and reset in correct 

operation should never be asserted at the same time. With regards to lOSetlnByte and lOLoadlnByte, if 

lOSetlnByte is asserted, it will set InByte to be OxFF regardless of the setting of lOLoadlnByte. 

The two VAL units are validation units connected to the Tamper Prevention and Detection circuitry 

(described in Section 10.3.5 of the Architecture Overview chapter), each with an OK bit. The OK bit 

is set to 1 on PORstL, and ORed with the ChipOK values from both Tamper Detection Lines each 

cycle. The OK bit is ANDed with each data bit that passes through the unit. 

In the case of VALi, the effective byte output from the chip will always be 0 if the chip has been 

tampered with. Thus no useful output can be generated by an attacker. In the case of VAL2, the 

effective byte input to the chip will always be 0 if the chip has been tampered with. Thus no useful 

input can be chosen by an attacker. 

There is no need to verify the registers in the IOU since an attacker does not gain anything by 
destroying or modifying them. 

The current mode of the IOU is output as a 2-bit lOMode to allow the other units within the QA Chip 
to take correct action. lOMode is defined as shown in Table 372: 

Table 372. lOMode values 



Value 


Interpretation 


00 


Idle Mode 


01 


Program Mode 


10 


Active Mode 


11 


Trim Mode 
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The Logic blocks generate a 1 if the current lOMode is in Program Mode, Active Mode or Trim Mode 
respectively. The logic blocks are: 



LogiCn 


lOMode = 01 (Program) 


Logic 2 


IOMode = 10 (Active) 


Logic 3 


lOMode = 11 (Trim) 



12.1 State machine 

There are two state machines in the IOU running in parallel. The first is a byte-oriented state 
machine, the second is a bit-oriented state machine. The byte-oriented state machine keeps track 
of the operating mode of the QA Chip while the bit-oriented state machine keeps track of the low- 
level bit Rx/Tx protocol. 

The SDa and SCIk lines are connected to the respective pads on the QA Chip. The IOU passes each 
of the signals from the pads through 2 D-types to compensate for metastability on input, and then a 
further latch and comparitor to ensure that signals are only used if stable for 2 consecutive internal 
clock cycles. The circuit is shown in Section 12.1.1 below. 
12.1.1 Start/Stop control signals 

The StartDetected and StopDetected control signals are generated based upon monitoring SDa 
synchronized to SCIk. The StartDetected condition is asserted on the falling edge of SDa synchronized 
to SCIk, and the StopDetected condition is asserted on the rising edge of SDa synchronized to SCIk. 
In addition we generate feSCIk which is asserted on the falling edge of SCIk, and reSCIk which is 
asserted on the rising edge of SCIk. Finally, feSclkPrev is the value of feSCIk delayed by a single cycle. 
Figure 398 shows the relationship of inputs and the generation of SDaReg, reSCIk, feSCIk, feSclkPrev, 
StartDetected and StopDetected. 

The SDaRegSelect logic compensates for the 2:1 variation in clock frequency. It uses the length of the 
high period of the SCIk (from the saturating counter) to select between sda5, sda6 and sda7 as the 
valid data from 300ns before the falling edge of SCIk as follows. 

The minimum time for the high period of SCIk is 600ns. If the counter <= 4 (i.e. 5 or fewer cycles with 
SCIk = 1) then SDaReg output = sda5 (sample point is equidistant from rising and falling edges). If the 
counter = 5 or 6 (i.e. 6 or 7 samples where SCIk = 1 ) , then SDaReg output = sda6. If the counter = 7 
(the counter saturates when there are 8 samples of SCIk = 1 ), then SDaReg output = sda7. This is 
shown in pseducode below: 
If ( (count er 2 = 0) v (counter = 4)) 
SDaReg = scia5 

Elself (counter = 7) 
SDaReg = sda7 

Else 
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SDaReg = sda6 
Endlf 

The counter also provides a means of enabling start and stop detection. There is a minimum of a 
600ns setup and 600ns hold time for start and stop conditions. At 14MHz this means samples 4 and 
5 5 after the rising edge (sample 1 is considered to be the first sample where SCIk = 1) could 
potentially include a valid start or stop condition. At 7 MHz samples 4 and 5 represent 284 and 
355ns respectively, although this is after the rising edge of SCIk, which itself is 100ns after the setup 
of data (i.e. 384 and 455ns respectively and therefore safe for sampling). Thus the data will be 
stable (although not a start or stop). Since we detect stops and starts using sda5 and sda6, we can 

1 0 only validly detect starts and stops 6 cycles after a rising edge, and we need to not-detect starts and 
stops 4 cycles before the falling edge. We therefore only detect starts and stops when the counter is 
>= 6 (i.e. when sclk3 and sclk2 are 0 and 1 respectively, sda2 holds sample 1 coincident with the ris- 
ing edge, sdal holds sample 2, sdaO holds sample 3, we load the counter with 0 and sample SDa to 
obtain the new sdaO which will hold sample 4 at the end of the cycle. Thus while the counter is 

1 5 incrementing from 0 to 1 , sdaO will hold sample 4. Therefore sample 4 will be in sda6 when the 
counter is 6. 

12.1 .2 Control of SDa and SCIk pins 

The SCIk line is always driven by the master. The SDa line is driven low whenever we want to 
transmit an ACK (SDa is active low) or a 0-bit from OutByte. The generation of the SDa pin is shown in 
20 the following pseudocode: 

TxAck = (bitSM_state = ack) a ( (byteSM_state = doWrite) v 

( ( (byteSM_state = getGlobalCmd) v (byteSM_state = checkld) ) a 
AckCmd) ) 

TxBit <r- (byteSM_state = doRead) a (bitSM_state = xferBit) a 
25 -OutByte^ bit c 0 unt 

SDa = -i(TxAck v TxBit) # only drive the line when we are xmitting 
a 0 

The slew rate of the SDa line should be restricted to minimise ground bounce. The pad must 
guarantee a fall time > 20ns. The rise time will be controlled by the external pull up resistor and bus 
30 capacitance. 

1 2.1 .3 Bit-oriented state machine 

The bit-oriented state machine keeps track of the general flow of serial transmission 
including start/data/ack/stop as shown in the following pseudocode: 

idle 

35 EndByte = FALSE 

EndAck = FALSE 
If (StartDetected) 
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state <r- starting 
Else 

state <- idle 
Endlf 

starting 

EndByte = FALSE 
EndAck = FALSE 
NAck <- 0 
If (StopDetected) 

state <— idle 
Elself (feSClkPrev) 

bitCount <- 0 

state <r- xferBit 
Else 

state <r- starting* includes StartDetected 
Endlf 

xferBit 

EndAck = FALSE 

EndByte = (feSclkPrev a (bitCount =0)) # after feSclk bitCount 
must be 1 . . 8 
If (feSClk) 

shiftLeft [ioByte, SDaReg] # capture the bit in the ioByte 
shift register 

bitCount <- bitCount + 1 # modulo count due to 3 bit bitCount 
Endlf 

If (StopDetected) 

state <— idle 
Elself (StartDetected) 

state <r- starting 
Elself (EndByte) 

state <— ack 
Else 

state <- xferBit 
Endlf 
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ack 

EndByte = FALSE 
EndAck = feSclkPrev 
If (StopDetected) 

state <— idle 
Elself (Start Detected) 

state <— starting 
Elself (EndAck) 

state <- xferBit # bitCount is already 0 
Else 

If (feSClk) 

NAck <- SDaReg # active low, so 0 = ACK, 1 = NACK 

Endlf 

state <— ack 
Endlf 

1 2.1 .4 Byte-oriented state machine 

The following pseudocode illustrates the general startup state of the IOU and the receipt of a 
transmission from the master. 

rstL # setup state of registers on reset 

IOMode <r- ActiveMode # to force the fuse to be loaded 
OutByteValid <- 0 
OutByte <- 0 

InByteValid <r- 1 # required 

InByte <- OxFF # byte = FF = the x reset' command 

localld <r- 0 # loads localld with the globalld so no localld 
exists 

state <— wait4fuse 
wait4 f use 

If (MIUAvail) 

If (FuseBlown) # this must be done same cycle as seeing 
MIUAvail go high 

state <— wait4cpu 
Else 

IOMode <— IdleMode # CPU will now require an external 
ActiveMode to start 
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state <— idle 

Else 

state <— wait4fuse 
Endlf 

wait4cpu 

If (CPUOutByteWE) # wait for CPU reset activities to finish 

state <— idle # note: we're still in ActiveMode 

Else 

state <— wait4cpu 
Endlf 



idle 

If (StartDetected) 

state <- checkld 
Else 

state <— idle 
Endlf 

The first byte received must be checked to ensure it is meant for everyone (globalld of 0) or 
specifically for us (localld matches). We only send an ACK to a read when there is data available to 
send. In addition, writes to the general call address (0) are always ACKed, but reads from the 
general call address are only ACKed before the fuse has been blown. 

checkld 

isWrite = (ioByte 0 = 0) 
isRead = {ioByte 0 = 1) 
isGlobal = (ioByte 7 _i = 0) 
globalW = isGlobal a isWrite 

localW = (ioByte 7 _! = locallD) a isWrite a -lisGlobal 
localR = (ioByte 7 . 1 = locallD) a isRead a (-.GlobalW 
-iFuseBlown) 

If (StopDetected) 

state idle 
Elself (EndByte) 

AckCmd_in = (globalW v localW) v (localR a OutByteValid) 

AckCmd <— AckCmd_in 

If (localW) 
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IOMode <— IdleMode # jic - any output was pending 
IOOutByteUsed = 1 

IOClearlnByte =1 # ensure there is nothing hanging around 
from before 
Endlf 
Elself (EndAck) 

If (globalW) # globalW and localW are mutually exclusive 

state <— getGlobalCmd 
Elself (localW) 

IOMode <— ActiveMode 

IOLoadlnByte = 1 # will set inByte to localW (lsb will be 

0) 

state <- doWrite 
Elself (localR a IOModei a AckCmd) # Active mode (or Trim 
when fuse intact ) 

state <— doRead 
Else 

state <— idle # ignore reads unless first in active or 
trim mode 
Endlf 
Else 

state <— checkld 
Endlf 

With a new global command the IOU waits for the mode byte (see Table page6 on page 934) 
to determine the new operating mode: 

getGlobalCmd 

wantProg = ( (ioByte = ProgramModeld) a -.FuseBlown) 
wantTrim = ( (ioByte = TrimModeld) a -.FuseBlown) 
wantActive = (ioByte = Act iveModeld) 
If (StopDetected) 

state <— idle 
Elself (StartDetected) 

state <— checkld 
Elself (EndByte) 

AckCmd_in = wantActive v wantProg v wantTrim # only ACK cmds 
we can do 
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AckCmd <— AckCmd_in 
If (AckCmd_in) 

IOMode <— IdleMode # jic - any output was pending 

IOOutByteUsed = 1 

IOClearlnByte =1 # ensure there is nothing hanging around 
from before 
Endlf 
Elself (EndAck) 
If (wantProg) 

IOMode <- ProgramMode # don't load inByte (we only want the 

data) 

state <— doWrite 
Elself (wantTrim) 

IOMode <- TrimMode # don't load InByte (we only want the 
next byte) 

state <— doWrite 
Elself (wantActive) # must be Active 

IOMode <- ActiveMode 

IOSetlnByte =1 #0 for all other cases & states. 1 = sets 
inByte to OxFF 

IOLoadlnByte = 1 # sets InByteValid (InByte is set to OxFF 
( 'reset' cmd) ) 

state <— wait4cpu# don't do anything til the cpu has 
completed this task 
Else 

state <— idle # unknown id, so ignore remainder 
Endlf 
Else 

state <- getGlobalCmd 
Endlf 

When the master writes bytes to the QA Chip (e.g. parameters for a command), the program must 
consume the byte fast enough (i.e. during the sending of the ACK) or subsequent bits may be lost. 
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The process of receiving bytes is shown in the following pseudocode: 

doWrite 

If (StopDetected) 

state <- idle # stay in whatever IOMode we 

were in 

Elself (Start Detected) 

state <— checkld 
Else 

If (EndByte) 

IOLoadlnByte = -.InByteValid 
Endlf 

If (EndByte a InByteValid) # will only be when master sends 
data too quickly 

state <- idle # ACK will not 

be sent when in idle state 

Else 

state <r- doWrite # ACK will be sent automatically after 
byte is Rxed 
Endlf 
Endlf 

When the master wants to read, the IOU sends one byte at a time as requested. The process is 
shown in the following pseudocode: 

doRead 

If (StopDetected) 

state <— idle 
Elself (Start Detected) 

state <— checkld 
Elself (EndAck) 

If (NAck v -.OutByteValid) 

state <— idle 
Else 

state <— doRead 
Endlf 
Else 

If (EndByte) 

IOOutByteUsed = 1 
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Endlf 

state <— doRead 
Endlf 

1 3 Fetch and Execute Unit 

5 13.1 Introduction 

The QA Chip does not require the high speeds and throughput of a general purpose CPU. It must 
operate fast enough to perform the authentication protocols, but not faster. Rather than have 
specialized circuitry for optimizing branch control or executing opcodes while fetching the next one 
(and all the complexity associated with that), the state machine adopts a simplistic view of the 
1 0 world. This helps to minimize design time as well as reducing the possibility of error in 
implementation. 

The FEU is responsible for generating the operating cycles of the CPU, stalling appropriately during 
long command operations due to memory latency. 

When a new transaction begins, the FEU will generate a JPZ (jump to zero) instruction. 
1 5 The general operation of the FEU is to generate sets of cycles: 

Cycle 0: fetch cycles. This is where the opcode is fetched from the program memory, and the 
effective address from the fetched opcode is generated. The Fetch output flag is set during the 
final cycle 0 (i.e. when the opcode is finally valid). 

Cycle 1 : execute cycle. This is where the operand is (potentially) looked up via the generated 
20 effective address (from Cycle 0) and the operation itself is executed. The Exec output flag is 

set during the final cycle 1 (i.e. when the operand is finally valid). 
Under normal conditions, the state machine generates multiple Cycle=0 followed by multiple Cycle=1. 
This is because the program is stored in flash memory, and may take multiple cycles to read. In 
addition, writes to and erasures of flash memory take differing numbers of cycles to perform. The 
25 FEU will stall, generating multiple instances of the same Cycle value with Fetch and Exec both 0 until 
the input MIURdy = 1, whereupon a Fetch or Exec pulse will be generated in that same cycle. 
There are also two cases for stalling due to serial I/O operations: 

The opcode is ROR OutByte, and OutByteValid = 1. This means that the current operation requires 
outputting a byte to the master, but the master hasn't read the last byte yet. 
30 • The operation is ROR InByte, and InByteValid = 0. This means that the current operation requires 
reading a byte from the master, but the master hasn*t supplied the byte yet. 
In both these cases, the FEU must stall until the stalling condition has finished. 
Finally, the FEU must stop executing code if the IOU exits Active Mode. 

The local Cmd opcode/operand latch needs to be parity-checked. The logic and registers contained 
35 in the FEU must be covered by both Tamper Detection Lines. This is to ensure that the instructions 
to be executed are not changed by an attacker. 
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13.2 State Machine 

The Fetch and Execute Unit (FEU) is combinatorial logic with the following registers: 

Table 373. FEU Registers 



Name 


tfbits 


Description 


Output registers (visible outside the FEU) 


Cycle 


1 


0 if the FEU is currently fetching an opcode, 1 if the 
FEU is currently executing the opcode. 


NewMemTrans 


1 


Is asserted during the start of a potential new memory 
access. 

0 = this is not the first cycle of a set of Cycle 0 or Cycle 
1 

1 = this is the first cycle of a set of Cycle 0 or Cycle 1 
(previous cycle must have been a Fetch or an Exec). 






Go 


1 


1 if the FEU is currently fetching and executing 
program code (i.e. a program is currently running), 0 if 
it is not. 


Local registers (not visible outside the FEU) 


CurrCmd 


8+p 


Holds the currently executing instruction (parity 
checked). 


PendingKill 


1 


The currently executing program is waiting to be halted 
(waiting due to memory access) 


PendingStart 


1 


A new transaction is waiting to be started (waiting due 
to memory access or an existing transaction not yet 
stopped) 


Wasldle 


1 


The previous cycle had an lOMode of IdleMode. 



5 

In addition, the following externally visible outputs are generated asynchronously: 
Table 374. Externally visible asynchronous FEU outputs 



Name 


#bits 


Description 


Fetch 


1 


1 if the FEU is performing the final cycle of a fetch (i.e. 
Cycle will also be 0). It is set when the NextCmd 
output is valid. The local Cmd register is latched during 
the Fetch cycle with either the incoming MIU8Data or 
an FEU-generated command. 
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Exec 


1 


1 if the FEU is performing the final cycle of an execute 
(i.e. Cycle will also be 1). It is set when the data 
required by the opcode from the MIU is valid. Other 
units can execute the Cmd and latch data from the 
MIU (e.g. from MIUData) during the Exec cycle. 


Cmd 


8 


When Cycle = 0, this holds the next instruction to be 
executed (during the next Cycle = 1). Is generated 
based on incoming MIU8Data or substituted FEU 
command (e.g. JSR 0). 

When Cycle = 1 , this holds the current instruction 
being executed (based on theCmd). 



The Cycle and currCmd registers are not used directly. Instead, their outputs are passed through a 
VAL unit before use. The VAL units are designed to validate the data that passes through them. 
Each contains an OK bit connected to both Tamper Prevention and Detection Lines. The OK bit is 
5 set to 1 on PORstL, and ORed with the ChipOK values from both Tamper Detection Lines each 
cycle. The OK bit is ANDed with each data bit that passes through the unit. 
In the case of VALi, the effective Cycle will always be 0 if the chip has been tampered with. Thus no 
program code will execute. 

In the case of VAL2, the effective 8-bit currCmd value will always be 0 if the chip has been tampered 
1 0 with. Multiple 0s will be interpreted as the JSR 0 instruction, and this will effectively hang the CPU. 
VAL2 also performs a parity check on the bits from currCmd to ensure that currCmd has not been 
tampered with. If the parity check fails, the Erase Tamper Detection Line is triggered. For more 
information on Tamper Prevention and Detection circuitry, see Section 10.3.5 on page 962. 
13.2.1 Pseudocode 
15 reset conditions: 

Fetch = 0 

Exec = 0 

Cycle <- 0 

currCmd <— 0 
20 Go <- 0 

pendingKill <— 0 

pendingStart <- 0 

newMemTrans <— 0 

wasldle <- 1 # required to detect if IOU starts in a non-idle 
25 state 



982 



The cycle by cycle combinatorial logic behaviour is shown in the following 
pseudocode: 

isActive = (IOMode = ActiveMode) 
wasldle <— (IOMode = IdleMode) 

wantToStart = (pendingStart v wasldle) a isActive 
newTrans = wantToStart a -.Go a MIUAvail 
pendingStart <— wantToStart a -.newTrans 
killTrans = Go a (-.isActive v pendingKill) 

Fetch = newTrans v (Go a -.Cycle a MIURdy a -ikillTrans) 
inDelay = (currCmd = ROR InByte) a -ilnByteValid 
outDelay = (currCmd = ROR OutByte) a OutByteValid 
ioDelay = inDelay v outDelay 
Exec = Go a Cycle a MIURdy a -.ioDelay 

If (Cycle) 

Cmd = currCmd 
Elself (newTrans) 

Cmd = JPZ # jump to 0 
Else 

Cmd = MIU8Data 
Endlf 

resetGo = (MIURdy a killTrans) v (Fetch a (Cmd = HALT)) 
pendingKill <r- killTrans a -.resetGo 

changeCycle = Fetch v Exec # will only be 1 when 

Cycle <- newTrans v ( (Cycle 0 changeCycle) a -.resetGo) 
newMemTrans <— newTrans v (changeCycle a -.resetGo) 
If (Fetch) 

currCmd <— Cmd 
Endlf 

If (resetGo) 

Go <- 0 
Elself (newTrans) 
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Go <- 1 
Endlf 
14 ALU 

The Arithmetic Logic Unit (ALU) contains a 32-bit Acc (Accumulator) register as well as the circuitry 
for simple arithmetic and logical operations. 

The logic and registers contained in the ALU must be covered by both Tamper Detection Lines. 
This is to ensure that keys and intermediate calculation values cannot be changed by an attacker. 
In addition, the Accumulator must be parity-checked. 

A 1-bit Z signal represents the state of zero-ness of the Accumulator. The Accumulator is cleared to 0 
upon a RstL, and the Z signal is set to 1 . The Accumulator is updated for any of the commands: AND, 
OR, XOR, ADD, ROR, and RIA, and the Z signal is updated whenever the Accumulator is updated. Note 
that the Z signal is actually implemented as a nonZ register whose output is passed through an 
inverter and used as Z. 

Each arithmetic and logical block operates on two 32-bit inputs: the current value of the Accumulator, 
and the current 32-bit output of the DataSel block (either the 32 bit value from MIUData or an 
immediate value). The AND, OR, XOR and ADD blocks perform the standard 32-bit operations. The 
remaining blocks are outlined below. 
Figure 399 shows a block diagram of the ALU: 

The Accumulator is updated for all instructions where the high bit of the opcode is set: 



Logic! 



Exec a Cmd 7 



Since the WriteEnables of Acc and nonZ takes Cmdz and Exec into account (due to Logici), these two bits 
are not required by the multiplexor MXi in order to select the output. The output selection for MXi 
only requires bits 6-3 of the Cmd and is therefore simpler as a result (as shown in Table 375). 

Table 375. Selection for multiplexor MX 1 





Output 


Cmd6-3 


MX, 


immOut 


Ollx v 1110 (LD) 




rorOut 


lOOx v 1111 (RIA, ROR) 


from XOR 


OOlx v 1100 (XOR) 


from ADD 


OlOx v 1101 (ADD) 


from AND 


0000 v 1010 (AND) 


from OR 


0001 v 1011 (OR) 



The two VAL units are validation units connected to the Tamper Prevention and Detection circuitry 
(described in Section 10.3.5 on page 962), each with an OK bit. The OK bit is set to 1 on PORstL, and 
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ORed with the ChipOK values from both Tamper Detection Lines each cycle. The OK bit is ANDed 
with each data bit that passes through the unit. 

In the case of VALi, the effective bit output from the Accumulator will always be 0 if the chip has been 
tampered with. This prevents an attacker from processing anything involving the Accumulator. VALi 
5 also performs a parity check on the Accumulator, setting the Erase Tamper Detection Line if the check 
fails. 

In the case of VAL2, the effective Z status of the Accumulator will always be true if the chip has been 
tampered with. Thus no looping constructs can be created by an attacker. 
14.1 DataSel Block 
1 0 The DataSel block is designed to implement the selection between the MIU32Data and the 
immediate addressing mode for logical commands. 

Immediate addressing relies on 3 bits of operand, plus an optional 8 bits at PC+1 to determine an 8- 
bit base value. Bits 0 to 1 determine whether the base value comes from the opcode byte itself, or 
from PC+1 , as shown in Table 376. 
1 5 Table 376. Selection for base value in immediate mode 



Cmd<i_o 


Base value 


00 


00000000 


01 


00000001 


10 


From PC+1 (i.e. MIUData 31 _ 24 ) 


11 


11111111 



The base value is computed by using CMDo as bit 0, and copying CMDi into the upper 7 bits. 
The 8-bit base value forms the lower 8 bits of output. These 8 bits are also ANDed with the sense of 
20 whether the data is replicated in the upper bits or not (i.e. CMD2). The resultant bits are copied in 3 
times to form the upper 24 bits of the output. 
Figure 400 shows a block diagram of the ALU's DataSel block: 
14.2 ROR Block 

The ROR block implements the ROR and RIA functionality of the ALU. 
25 A 1-bit register named RTMP is contained within the ROR unit. RTMP is cleared to 0 on a RstL, and 
set during the ROR RB and ROR XRB commands. The RTMP register allows implementation of Linear 
Feedback Shift Registers with any tap configuration. 
Figure 401 shows a block diagram of the ALU's ROR block: 

The ROR n, blocks are shown for clarity, but in fact would be hardwired into multiplexor MX3, since 
30 each block is simply a rewiring of the 32-bits, rotated right n bits. 

Logici is used to provide the WriteEnable signal to RTMP. The RTMP register should only be written to 
during ROR RB and ROR XRB commands. The combinatorial logic block is: 
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Logic! 



Exec a (Cmd 7 -4 = ROR) a (Cmd^i = 000) 



Multiplexor MXi performs the task of selecting the 6-bit value from Cn instead of bits 1 3-8 (6 bits) 
from Acc (the selection is based on the value of Logic2). Bit 5 is required to distinguish ROR from 
RIA. 



Logic 2 Cmd5-2 = 0x10 



Table 377. Selection for multiplexor MX 1 





Output 


Logic 2 


MX, 


Cn 


1 




Acc 13 -8 


0 



Multiplexor MX2 performs the task of selecting the 8-bit value from InByte instead of the lower 8 bits 
1 0 from the ANDed Acc based on the CMD. 

Table 378. Selection for multiplexor MX 2 





Output 


Cmd4_o 


MX 2 


InByte 


0x110 




ACC7-0 


^(0x110) 



Multiplexor MX3 does the final rotating of the 32-bit value. The bit patterns of the CMD operand are 
1 5 taken advantage of: 

Table 379. Selection for multiplexor MX 3 





Output 


Cmdj-o 


Comments 


MX 3 


ROR 1 


OOxx 


RB. XRB, WriteMask, 1 




ROR 3 


OlOx 


3 


ROR 31 


0110 


31 


ROR 24 


0111 


24 


ROR 8 


lxxx 


RIA, InByte, 8, OutByte, C1, C2, 
ID 



20 14.3 IO Block 
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The IO block within the ALU implements the logic for communicating with the IOU during 
instructions that involve the Accumulator. This includes generating appropriate control signals and 
for generating the correct data for sending during writes to the lOU's OutByte and Localld registers. 
Figure 402 shows a block diagram of the IO block: 
5 Logici is used to provide the LocalldWE signal to the IOU. The localld register should only be written 
to during the ROR ID command. Only the lower 7 bits of the Accumulator are written to the localld 
register. 

LogiC2 is used to provide the ALUOutByteWE signal to the IOU. The OutByte register should only be 
written to during the ROR OutByte command. Only the lower 8 bits of the Accumulator are written to 
1 0 the OutByte register. 

In both cases we output the lower 8 bits of the Accumulator. The ALUIOData value is ANDed with the 
output of LogiC2 to ensure that ALUIOData is only valid when it is safe to do so (thus the IOU logic 
never sees the key passing by in ALUIOData). The combinatorial logic blocks are: 



Logid 



Logic 2 



Exec a (Cmd 7 _o = ROR ID) 



Exec a (Cmd 7 -o = ROR OutByte) 



1 5 Logic3 is used to provide the ALUInByteUsed signal to the IOU. The InByte is only used during the 

ROR InByte command. The combinatorial logic is: 



Logic 3 



Exec a (Cmd 7 ^ = ROR InByte) 



1 5 Program Counter Unit 

The Program Counter Unit (PCU) includes the 12 bit PC (Program Counter), as well as logic for 
20 branching and subroutine control. 

The PCU latches need to be parity-checked. In addition, the logic and registers contained in the 
PCU must be covered by both Tamper Detection Lines to ensure that the PC cannot be changed by 
an attacker. 

The PC is implemented as a 12 entry by 12-bit PCA (PC Array), indexed by a 4-bit SP (Stack 
25 Pointer) register. The PC, PCRamSel and SP registers are all cleared to 0 on a RstL, and updated 
during the flow of program control according to the opcodes. 

The current value for the PC is normally updated during the Execute cycle according to the command 
being executed. However it is also incremented by 1 during the Fetch cycle for two byte instructions 
such as JMP, JSR, DBR, TBR, and instructions that require an additional byte for immediate 
30 addressing. The mechanism for calculating the new PC value depends upon the opcode being 
processed. 

Figure 403 shows a block diagram of the PCU: 
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The ADD block is a simple adder modulo 2 12 with two inputs: an unsigned 12 bit number and an 8- 
bit signed number (high bit = sign). The signed input is either a constant of 0x01, or an 8-bit offset 
(the 8 bits from the MIU). 

The "+1" block takes a 4-bit input and increments it by 1 (modulo 12). The "-1" block takes a 4-bit 
input and decrements it by 1 (modulo 12). 
Table 380 lists the different forms of PC control: 

Table 381 . Different forms of PC control during the Exec cycle 



Command 


Action 


JMP 


The PC is loaded with the current 12-bit value as passed in from 
the MIU. 


JPI 


The PC is loaded with the current 1 2-bit value as passed in from 
the Acc. 

PCRamSel is loaded with the value from bit 15 of the Acc. 


JPZ 


The PC is loaded with 0. PCRamSel is loaded with 0 (program in 
flash) 


JoZ. 


oave oia value ot ru onto stacK tor later. 1 ne HO is loaded with 
0. PCRamSel is loaded with 0 (program in flash). 


JSR, JSI 


Save old value of PC onto stack for later. The PC is loaded with 
the current 12-bit value as passed in from either the MIU or the 
Acc. With JSI, PCRamSel is loaded from the value in bit 15 of the 
Accumulator. I 


RTS 


Pop old value of PC from stack and increment by 1 to get new 
PC. 


TBR 


f the 2 flag matches the TBR test, add 8-bit signed number 
(MIU8Data) to current PC. Otherwise increment current PC by 1 . 


DBR 


f the CZ flag is set, add 8-bit signed offset (MIU8Data) to current 
PC. Otherwise increment current PC by 1 . 


All others 


ncrement current PC by 1 



The updating of PCRamSel only occurs during JPI, JSI, JPZ and JSZ instructions, detected via Logico. 
The same action for the Exec takes place for JMP, JSR, JPI, JSI, JPZ and JSZ, so we specifically detect 
that case in Logici. In the same way, we test for the RTS case in LogiC2. 



Logico 


Cmd 7 -i = 011x001 


LogiCi 


(Cmd 7 - 5 = 000) v Logico 


Logic 2 


Cmd7_o = RTS 
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When updating the PC, we must decide if the PC is to be replaced by a completely new value (as in 
the case of the JMP, JSR, JP1, JSI, JPZ and JSZ instructions), or by the result of the adder (all other 
instructions). The output from Logici ANDed with Cycle can therefore be safely used by the 
5 multiplexor to obtain the new PC value (we need to always select PC+1 when Cycle is 0, even 
though we don't always write it to the PCA). 

Note that the JPZ and JSZ instructions are implemented as 12 AND gates that cause the Accumulator 
value to be ignored, and the new PC to be set to 0. Likewise, the PCRamSel bit is cleared via these 
two instructions using the same AND mechanism. 
1 0 The input to the 12-bit adder depends on whether we are incrementing by 1 (the usual case), or 
adding the offset as read from the Mill (when a branch is taken by the DBR and TBR instructions). 
LogiC3 generates the test. 



Logic 3 



Cycle a (((Cmd 7 -4 = DBR )a^CZ)v ((Cmd 7 -4 = TBR) a (Cmd 0 0 Z))) 



The actual offset to be added in the case of the DBR and TBR instructions is either the 8-bit value 
1 5 read from the MIU, or an 8-bit value generated by bits 3-1 of the opcode and treating bit 4 of the 
opcode as the sign (thereby making DBR immediate branching negative, and TBR immediate 
branching positive). The former is selected when bits 3-1 of the opcode is 0, as shown by Logics 



Logic 4 



If (Cmd^ = 000) output MIU8Data 

Else output Cmd 4 | Cmd 4 | Cmd 4 | Cmd 4 | Cmd 4 | Cmd 3 .i 



Finally, the selection of which PC entry to use depends on the current value for SP. As we enter a 
20 subroutine, the SP index value must increment, and as we return from a subroutine, the SP index 
value must decrement. Logici tells us when a subroutine is being entered, and LogiC2 tells us when 
the subroutine is being returned from. We use LogiC2 to select the altered SP value, but only write to 
the SP register when Exec and CmcU are also set (to prevent JMP and JPZ from adjusting SP). 
The two VAL units are validation units connected to the Tamper Prevention and Detection circuitry 
25 (described in Section 10.3.5 on page 962), each with an OK bit. The OK bit is set to 1 on PORstL, and 
ORed with the ChipOK values from both Tamper Detection Lines each cycle. The OK bit is ANDed 
with each data bit that passes through the unit. Both VAL units also parity-check the data bits to 
ensure that they are valid. If the parity-check fails, the Erase Tamper Detection Line is triggered. 
In the case of VALi, the effective output from the SP register will always be 0. If the chip has been 
30 tampered with. This prevents an attacker from executing any subroutines. 

In the case of VAb, the effective PC output will always be 0 if the chip has been tampered with. This 
prevents an attacker from executing any program code. 
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16 Address Generator Unit 

The Address Generator Unit (AGU) generates effective addresses for accessing the Memory Unit 
(MU). In Cycle 0, the PC is passed through to the MU in order to fetch the next opcode. The AGU 
5 interprets the returned opcode in order to generate the effective address for Cycle 1 . In Cycle 1, the 
generated address is passed to the MU. 

The logic and registers contained in the AGU must be covered by both Tamper Detection Lines. 

This is to ensure that an attacker cannot alter any generated address. The latches for the counters 

and calculated address should also be parity-checked. 
10 If either of the Tamper Detection Lines is broken, the AGU will generate address 0 each cycle and 

all counters will be fixed at 0. This will only come into effect if an attacker has disabled the RESET 

and/or erase circuitry, since under normal circumstances, breaking a Tamper Detection Line will 

result in a RESET or the erasure of all Flash memory. 

16.1 Implementation 
1 5 The block diagram for the AGU is shown in Figure 404: 

The accessMode and WriteMask registers must be cleared to 0 on reset to ensure that no access to 

memory occurs at startup of the CPU. 

The Adr and accessMode registers are written to during the final cycle of cycle 0 (Fetch) and cycle 1 
(Exec) with the address to use during the following cycle phase. For example, when cycle = 1 , the PC 
20 is selected so that it can be written to Adr during Exec. During cycle 0, while the PC is being output 

from Adr, the address to be used in the following cycle 1 is calculated (based on the fetched opcode 
seen as Cmd) and finally stored in Adr when Fetch is 1 . The accessMode register is also updated in the 
same way. 

It is important to distinguish between the value of Cmd during different values for Cycle: 
25 • During Cycle 0, when Fetch is 1 , the 8-bit input Cmd holds the instruction to be executed in the 
following Cycle 1. This 8-bit value is used to decode the effective address for the operand of 
the instruction. 

During Cycle 1, when Exec is 1 , Cmd holds the currently executing instruction. 
The WriteMask register is only ever written to during execution of an appropriate ROR instruction. 
30 Logici sets the WriteMask and MMR WriteEnables respectively based on this condition: 



Logic! 



Exec a (Cmd 7 -o = ROR WriteMask) 



The data written to the WriteMask register is the lower 8 bits of the Accumulator. 

The Address Register Unit is only updated by an RIA or LIA instruction, so the writeEnable is 

generated by LogiC2 as follows: 



Logic 2 



Exec a (Cmde-3 = 1111) 



The Counter Unit 



;CU) generates counters C1, C2 and the selected N index. In addition, the CU 



35 outputs a CZ flag for use by the PCU. The CU is described in more detail below. 
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The VALi unit is a validation unit connected to the Tamper Prevention and Detection circuitry 
(described in Section 10.3.5 on page 962). It contains an OK bit that is set to 1 on PORstL, and 
ORed with the ChipOK values from both Tamper Detection Lines each cycle. The OK bit is ANDed 
with the 12 bits of Adr before they can be used. If the chip has been tampered with, the address 
5 output will be always 0, thereby preventing an attacker from accessing other parts of memory. The 
VALi unit also performs a parity check on the Adr Address bits to ensure it has not been tampered 
with. If the parity-check fails, the Erase Tamper Detection Line is triggered. 

16.1.1 Counter Unit 

The Counter Unit (CU) generates counters C1 and C2 (used internally). In addition, the CU outputs 
10 Cn and flag CZ for use externally. The block diagram for the CU is shown in Figure 405: 

Registers C1 and C2 are updated when they are the targets of a DBR, SC or ROR instruction. Logici 
generates the control signals for the write enables as shown in the following pseudocode. 

isDbrSc = (Cmd 7 - 4 = DBR) v (Cmd 7 - 4 = SC) 
isRorCn = (Cmd 7 _ 4 = ROR) a (Cmd 3 _ 2 = 10) 

15 

CnWE = Exec a (isDbrSc v isRorCn) 
Clwe = CnWE a -iCmd 0 
C2we = CnWE a Cmd 0 

The single bit flag CZ is produced by the NOR of the appropriate C1 or C2 register for use during a 
20 DBR instruction. Thus CZ is 1 if the appropriate Cn value = 0. 

The actual value written to C1 or C2 depends on whether the ROR, DBR or SC instruction is being 
executed. During a DBR instruction, the value of either C1 or C2 is decremented by 1 (with wrap). 
One multiplexor selects between the lower 6 bits of the Accumulator (for ROR instructions), and a 6- 
bit value for an SC instruction where the upper 3 bits = the low 3 bits from C2, and low 3 bits = low 
25 3 bits from Cmd. Note that only the lowest 3 bits of the operand are written to C1. 

The two VAL units are validation units connected to the Tamper Prevention and Detection circuitry 
(described in Section 10.3.5 on page 962), each with an OK bit. The OK bit is set to 1 on PORstL, and 
ORed with the ChipOK values from both Tamper Detection Lines each cycle. The OK bit is ANDed 
with each data bit that passes through the unit. All VAL units also parity check the data to ensure the 
30 counters have not been tampered with. If a parity check fails, the Erase Tamper Detection Line is 
triggered. 

In the case of VALi, the effective output from the counter C1 will always be 0 if the chip has been 
tampered with. This prevents an attacker from executing any looping constructs. 
In the case of VAL.2, the effective output from the counter C2 will always be 0 if the chip has been 
35 tampered with. This prevents an attacker from executing any looping constructs. 

1 6.1 .2 Calculate Next Address 
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This unit generates the address of the operand for the next instruction to be executed. It makes use 
of the Address Register Unit and PC to obtain base addresses, and the counters from the Counter 
Unit to assist in generating offsets from the base address. 

This unit consists of some simple combinatorial logic, including an adder that adds a 6-bit number to 
a 10-bit number. The logic is shown in the following pseudocode. 

isErase = (Cmd 7 _ 0 = ERA) 
isSt = (Cmd 7 _ 4 = ST) 
isAccRead = (Cmd 7 -6 = 10) 

# First determine whether this is an immediate mode requiring PC+1 
isJmpJsrDbrTbrlmmed = (Cmd 7 . 6 =00) a (-.Cmd 5 v (Cmd 5 _i = 1x000)) 
isLia = (Cmd 7 _ 3 = LIA) 

isLoglmmed = ( (Cmd 7 > 6 = 11) a ( (Cmd 5 v Cmd 4 ) a (Cmd 5 _ 3 * 111))) a 
(Cmdi_o = 10) 

pcSel = Cycle v (-»Cycle a (isJmpJsrDbrTbrlmmed v isLoglmmed v 
isLia) ) 

# Generate AnSel signal for the Address Register Unit 
AOSel = (isAccRead v isSt) a (-iCmd 3 v (Cmd 5 - 3 = 001)) 
AnSeli-o = -.AOSel a Cmd 2 -i 

# The next address is either the new PC or must be generated 

# (we require the base address from Address Register Unit) 
nextRAMSel = AnDataOut 8 a -lisErase 

If (nextRAMSel) 

baseAdr = 00 | AnDataOut 7 _ 0 # ram addresses are already word 
aligned 
Else 

baseAdr = AnDataOut 7 _ 0 I 00 # flash addresses are 4 -byte aligned 
Endlf 

# Base address is now word (4-byte) aligned 

# Now generate the offset amount to be added to the base address 
selCn = (isAccRead v isSt) a (Cmd 5 v Cmd 4 ) a Cmd 3 

offseto = (AOSel a Cmd 0 ) v (selCn a Cn 0 ) 
offset! = (AOSel a CmdJ v (selCn a Cn x ) 
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offset 2 = (AOSel a Cmd 2 ) v (selCn a Cn 2 ) 
offset 5 - 3 = selCn a Cn 5 - 3 
If (isErase) 

nextEf f Adr n - 4 = Acc 7 - 0 
5 nextEf fAdr 3 , 0 - don't care 

Else 

# now we can simply add the offset to the base address to get 
the effective adr 

nextEf fAdru-2 = baseAdr + offset # 10 bit plus 6 bit, with wrap 
10 = 10 bits out 

nextEf fAdr 1 , 0 = 0 # word access, so lower bits of effadr are 0 
Endlf 

# Now generate the various signals for use during Cycle=l 

# Note that these are only valid when pcSel is 0 (otherwise will 
15 read PC) 

nextAccessMode 0 = 1 # want 32-bit access 

nextAccessModei = nextRAMSel # ram or flash access (only valid if 
rd/wr/erase set) 

nextAccessMode 2 = isAccRead # pcSel takes care of LIA instruction 
20 nextAccessMode 3 = isSt # write access 

nextAccessMode 4 = isErase # erase page access 
16.1.3 Address Register Unit 

This unit contains 4 x 9-bit registers that are optionally cleared to 0 on PORstL The 2-bit input AnSel 
selects which of the 4 registers to output on DataOut. When the writeEnable is set, the AnSel selects 
25 which of the 4 registers is written to with the 9-bit Dataln. 
17 Program Mode Unit 

The Program Mode Unit (PMU) is responsible for Program Mode and Trim Mode operations: 

Program Mode involves erasing the existing flash memory and loading the new program/data 
into the flash. The program that is loaded can be a bootstrap program if desired, and may 
30 contain additional program code to produce a digital signature of the final program to verify 

that the program was written correctly (e.g. by producing a SHA-1 signature of the entire flash 
memory). 

Trim Mode involves counting the number of internal cycles that have elapsed between the 
entry of Trim Mode (at the falling edge of the ack) and the receipt of the next byte (at the 
35 falling edge of the last bit before the ack) from the Master. When the byte is received, the 

current count value divided by 2 is transmitted to the Master. 
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The PMU relies on a fuse (implemented as the value of word 0 of the flash information block) to 
determine whether it is allowed to perform Program Mode operations. The purpose of this fuse is to 
prevent easy (or accidental) reprogramming of QA Chips once their purpose has been set. For 
example, an attacker may want to reuse chips from old consumables. If an attacker somehow 
5 bypasses the fuse check, the PMU will still erase all of flash before storing the desired program. 
Even if the attacker somehow disconnects the erasure logic, they will be unable to store a program 
in the flash due to the shadow nybbles. 

The PMU contains an 8-bit buff register that is used to hold the byte being written to flash and a 12- 
bit adr register that is used to hold the byte address currently being written to. 

1 0 The PMU is also used to load word 1 of the information block into a 32-bit register (combined from 
8-bits of buff, 12-bits of adr, and a further 12-bit register) so it can be used to XOR all data to and 
from memory (both Flash and RAM) for future CPU accesses. This logic is activated only when the 
chip enters ActiveMode (so as not to access flash and possibly cause an erasure directly after 
manufacture since shadows will not be correct). The logic and 32-bit mask register is in the PMU to 

1 5 minimize chip area. 

The PMU therefore has an asymmetric access to flash memory: 
writes are to main memory 
reads are from information block memory 
The reads and writes are automatically directed appropriately in the MRU. 

20 A block diagram of the PMU is shown in Figure 406. 

17.1 LOCAL STORAGE AND COUNTERS 

The PMU keeps a 1 -cycle delayed version of MRURdy, called prevMRURdy. It is used to generate 
PMNewTrans. Therefore each cycle the PMU performs the following task: 

25 prevMRURdy <- MRURdy v (state = loadByte) 

The PMU also requires 1-bit maskLoaded, idlePending and idlePending registers, all of which are cleared 
to 0 on RstL The 1-bit fuseBlown register is set to 1 on RstL for security. 

17.2 State machine 

30 The state machine for the PMU is shown in Figure 407, with the pseudocode for the 

various states outlined below. 

rstl 

prevMRURdy, maskLoaded, idlePending, adr <r- 0 #clear most regs 
fuseBlown <— 1 # for security sake assume the worst 
35 state <— idle 

The idle state, entered after reset, simply waits for the lOMode to enter 
ProgramMode, ActiveMode, or TrimMode. Note that the reset value for fuseBlown 
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means that ProgramMode and TrimMode cannot be entered until after a successful 
entry into ActiveMode that also clears the fuseBlown register. In state idle, PMEn = 
--.maskLoaded, and in state wait4Mode PMEn = 0. In all other states, PMEn = 1. 

idle 

idlePending 0 
PMEn = -.maskLoaded 
PMNewTrans = 0 

If ((IOMode = ActiveMode) a MRURdy) 
If (maskLoaded) 

state <- wait4mode # no need to reload mask once loaded 
Else 

adr <— 0 # the location of the fuse is within 32-bit word 

0 

state <— loadFuse 
Endlf 

Elself ((IOMode = ProgramMode) a MRURdy a -.fuseBlown) # wait 4 
access 2 finish 

maskLoaded <— 0 # the mask is now invalid 

adr <- 0 # the location of the fuse is within 32-bit word 0 

state <— loadFuse 
Elself ((IOMode = TrimMode) a MRURdy a -.fuseBlown) # wait 4 
access 2 finish 

maskLoaded <- 0 # the mask is now invalid 

adr <r- 0 # start the counter on entering TrimMode 

state <— trim 
Else 

state <— idle 
Endlf 

The wait4mode state simply waits until for the current mode to finish and returns to 
idle. 

wait4mode 
PMEn = 0 
PMNewTrans = 0 
If (IOMode = IdleMode) 

state <— idle 
Else 
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state <— wait4mode 
Endlf 

The trim state is where we count the number of cycles between the entry of the Trim Mode and the 
arrival of a byte from the Master. When the byte arrives from the Master, we send the resultant 
5 count: 

trim 

# We saturate the adder at all Is to make external trim control 
easier 

lastOne = adr 0 a adri a . . . adrn 
10 If (-ilastOne) 

adr = adr + 1 # 12 bit incrementor 
Endlf 

# This logic simply causes the current adder value to be written 
to the 

15 # outByte when the inByte is received. The inByte is cleared 

when received 

# although it is not strictly necessary to do so 
PMOutByteWE = InByteValid # 0 in all other states 

PMInByteUsed = InByteValid # same as in loadByte state, 0 in all 
20 other states 

If (IOMode * TrimMode) 

state <— idle 
Elself (InByteValid) 
state <— wait4mode 
25 Else 

state <— trim 
Endlf 

The loadFuse state is called whenever there is an attempt to program the device or we are entering 
ActiveMode and the mask is invalid (i.e. after power up or after a ProgramMode or TrimMode 
30 command). We load the 32-bit fuse value from word 0 of information memory in flash and compare 
it against the FuseSig constant (0x5555AAAA) to obtain the fuse value. The next state depends on 
IOMode and the Fuse. 

loadFuse 
PMEn = 1 

35 PMNewTrans = prevMRURdy 

idlePending_in = idlePending v (IOMode = IdleMode) 
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idlePending <— idlePending_in 
If (MRURdy) 

If (idlePending_in) # don't change state until the memory 
access is complete 

state <— idle 
Else 

fuseBlown_in = (MRUData 31 _ 0 = FuseSig) 
fuseBlown <— fuseBlown_in 
If (IOMode = ProgramMode) 
If ( f useBlown_in) 

state <- wait4mode # not allowed to program anymore 
Else 

state <— erase 
Endlf 

Elsif (IOMode = ActiveMode) 

adr <— 4 # byte 4 is word 1 (the location of the 

XORMask) 

state <r- getMask 
Else 

state <— idle 
Endlf 
Endlf 
Else 

state «— loadFuse 
Endlf 

The erase state erases the flash memory and then leads into the main programming states: 

erase 

PMNewTrans = prevMRURdy 

PMEraseDevice = 1 # is 0 in all other states 
adr <r- 0 

idlePending_in = idlePending v (IOMode * ProgramMode) 
idlePending <— idlePending_in 
If (MRURdy) 

If (idlePending_in) 
state <— idle 

Else 
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state «- loadByte 

Endlf 
Else 

state <— erase 
Endlf 

Program Mode involves loading a series of 8-bit data values into the Flash. The PMU reads bytes 
via the lOU's InByte and InByteValid, setting MUlnByteUsed as it loads data. The Master must send data 
slightly slower than the speed it takes to write to Flash to ensure that data is not lost. 

loadByte # Load in 1 byte (1 word) from 10 Unit 

PMNewTrans = 0 

PMInByteUsed = InByteValid # same as in Trimln state, and 0 in 
all other states 

If (IOMode * ProgramMode) 

state <— idle 
Else 

If (InByteValid) 

buff <— InByte 

state <- writeByte 
Else 

state <- loadByte 
Endlf 
Endlf 

writeByte 

PMNewTrans = prevMRURdy 

PMRW =0 # write. In all other states, PMRW = 1 (read) 

PM32Out 7 - 0 = buff # data (can be tied to this) 
PM320ut 19 _ 8 = adr # can be tied to this 

PM320ut 31 _2o = 12bitReg # is always this (is don't care during a 
write) 

idlePending_in = idlePending v (IOMode * ProgramMode) 
idlePending <r- idlePending_in 
If (MRURdy) 

lastOne = adr 0 a adr x a ... adrn 

adr <— adr + 1 # 12 bit incrementor 

If (idlePending_in) 
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state <- idle 
Elself (lastOne) 

state <- wait4Mode 
Else 

state <— loadByte 
Endlf 
Else 

state <— writeByte 
Endlf 

The getMask state loads up word 1 of the flash information block (bytes 4-7) into the 32-bit buffer so 
it can be used to XOR all data to and from memory (both Flash and RAM) for future CPU accesses. 

getMask 

PMNewTrans = prevMRURdy 

PM320uti9_ 8 = adr # adr should = 4, i.e. word 1 which holds the 
CPU' s mask 

PMRW =1 # read (MUST be 1 in this state) 

idlePending_in = idlePending v (IOMode * ActiveMode) 
idlePending <— idlePending_in 
If (MRURdy) 

buff <r- MRUData 7 _ 0 

adr <- MRUData 19 - 8 

12bitReg <r- MRUData 3 i_ 2 o 

maskLoaded <— 1 

If (idlePending_in) 
state <— idle 

Else 

state <- wait4mode 
Endlf 
Else 

state <r- getMask 
Endlf 

1 8 Memory Request Unit 

The Memory Request Unit (MRU) provides arbitration between PMU memory requests and CPU- 
based memory requests. 

The arbitration is straightforward: if the input PMEn is asserted, then PMU inputs are processed and 
CPU inputs are ignored. If PMEn is deasserted, the reverse is true. 
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A block diagram of the MRU is shown in Figure 408. 

18.1 Arbitration Logic 

The arbitration logic block provides arbitration between the accesses of the PM and the 8/32-bit 
accesses of the CPU via a simple multiplexing mechanism based on PMEn: 

ReqDataOut 3 i_ 8 = CPUDataOut 31 - 8 
If (PMEn) 

NewTrans = PMNewTrans 

AccessMode 0 = PMRW # maps to 1 for reads (32 bits), 0 for 
writes (8 bits) 

AccessModei =0 # flash accesses only 

AccessMode 2 = PMRW a -iPMEraseDevice # read has lower priority 
than erase 

AccessMode 3 = -nPMRW a -iPMEraseDevice # write has lower 
priority than erase 

AccessMode 4 =0 # pageErase 

AccessMode 5 = PMEraseDevice # erase everything (main & info 
block) 

WriteMask = OxFF 
Adr = PM320uti9_ 8 

ReqDataOut 7 - 0 = PM32Out 7 - 0 
Else 

NewTrans = CPUNewTrans a (CPUAccessMode 4 _ 2 * 000) 
AccessMode 4 _ 0 - CPUAccessMode 

AccessMode 5 = 0 # cpu cannot ever erase entire chip 
WriteMask = CPUWriteMask 
Adr = CPUAdr 

ReqDataOut 7 _ 0 = CPUDataOut 7 -o 
Endlf 

1 8.2 Memory Request Logic 

The Memory Request Logic in the MRU implements the memory requests from the selected input. 
An individual request may involve outputting multiple sub-requests e.g. an 8-bit read consists of 2 x 
4-bit reads (each flash byte contains a nybble plus its inverse). 

The input accessMode bits are interpreted as follows: 

Table 382. Interpretation of accessMode bits 



Bit 


Description 


0 


0 = 8-bit access 
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1 = 32-bit access 


1 


0 = flash access 

1 = RAM access 

this bit is only valid if bit 2, 3 or 4 is set 




1 = read access 


3 


1 = write access 


4 


1 = erase page access 


5 


1 = erase entire (info and main) flash (only used within the 
MRU) 



The MRU contains the following registers for general purpose flow control: 
Table 383. Description of register settings 



name 


tfbits 


Description 


ActiveTrans 


1 


Is there a transaction still running? If so, then 
extraTrans and 

nextToXfer can be considered valid. 


badUntilRestart 


1 


0 = memory (flash and ram) reads work correctly 

1 = memory (flash and ram) reads return 0 
Gets set whenever illChip gets set, and remains 
set until a soft restart occurs i.e. lOMode passes 
through Idle. 


extraTrans 


1 


Determines whether there is an additional sub- 
transaction to perform, e.g. a 32 bit read from flash 
involves 4 sub-transactions in the case of 8-bit 
accesses, and 8 sub-transactions in the case of 4- 
bit accesses. 


IllChip 


1 


0 = 15 consecutive bad reads have not occurred 
1=15 consecutive bad reads have occurred 


nextToXfer 


3 


The next element (byte or nybble) number to 
transfer to/from memory 


restartPending 


1 


1 = lOMode passed through Idle while a 
transaction was being processed 
0 = The transaction completed without lOMode 
passing through Idle 


retryCount 


4 


Number of times that a byte has been read badly 
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from flash. When a byte has been read badly 15 
consecutive times HlChip will be set. 


retryStarted 


1 


0 = no retries encountered yet for this read 

1 = retries have been encountered - retryCount 
holds the number of retries 

The retryStarted register is used to stop retryCount 
being cleared on good reads - thus keeping a 
record of the last number of retries on a bad read. 



Table 383 lists the registers specifically for testing flash. Although the complete set of flash test 
registers is in both the MRU and MAU (group 0 is in the MRU, groups 1 and 2 are in the MAU), all 
the decoding takes place from the MRU. 



10 

Table 383. Flash test registers settable from CPU when the RAM address is > 128 7 



adr 

bitSupe 
rscriptp 
aranum 
only 


bits 


name 


description 


0 


0 


shadowsOff 


0 = regular shadowing (nybble based access to 
flash) 

1 = shadowing disabled, 8-bit direct accesses to 
flash. 




1 


hiFlashAdr 


Only valid when shadowsOff = 1 

0 = accesses are to lower 4Kbytes of flash 

1 = accesses are to upper 4 Kbytes of flash 




2 





This is from the programmer's perspective. Addresses sent from the CPU are byte aligned, so the MRU needs to test 
bit n+2. Similarly, checking DRAM address > 128 means testing bit 7 of the address in the CPU, and bit 9 in the MRU. 
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1 


3 


enableFlashTest 


0 = keep flash test register within the TSMC flash 
IP in its reset state 

1 = enable flash test register to take on non-reset 
values. 




8-4 


flashTest 


Internal 5-bit flash test register within the TSMC 
flash IP (SFC008_08B9_HE). 
If this is written with 0x1 E, then subsequent 
writes will be according to the TSMC write test 
mode. You must write a non-0x1 E value or reset 
the register to exit this mode. 


2 


28-9 


flashTime 


When timerSel is 1, this value is used for the 
duration of the program cycle within a standard 
flash write or erasure. 1 unit = 16 clock cycles (16 
x 100ns typical). 

Regardless of timerSel, this value is also used for 
the timeout following power down detection 
before the QA Chip resets itself. 1 unit = 1 clock 
cycle (= 100ns typical). 

Note that this means the programmer should set 
this to an appropriate value (e.g. 5 jjs), just as the 
localld needs to be set. 




29 


timerSel 


0 = use internal (default) timings for flash writes & 
erasures 

1 = use flashTime for flash writes and erasures 



18.2.1 Reset 

Initialization on reset involves clearing all the flags: 

MRURdy =0 # can't process anything at this point 
5 activeTrans 4- 0 

extraTrans <— 0 
illChip <r- 0 
badUntilRestart <— 0 
restartPending <— 0 

8 unshadowed 

9 shadowed 



1003 



retryCount <— 0 
retryStarted <- 0 
nextToXfer ^-0 # don't care 
shadowsOff <— 0 
hiFlashAdr <— 0 

infoBlockSel <- 0# used to generate MRUMode 2 
Main logic 

The main logic consists of waiting for a new transaction, and starting an appropriate 
sub-transaction accordingly, as shown in the following pseudocode: 

# Generate some basic signals for use in determining 

access Patterns 

Is32Bit = AccessMode 0 

Is8Bit = -iAccessMode 0 

IsFlash = -lAccessModei 

IsRAM = AccessModei 

IsRead = AccessMode 2 

IsWrite = AccessMode 3 

noShadows = shadowsOff 

doShadows = IsFlash a -.noShadows 

continueRequest = (IOMode * IdleMode) 

okForTrans = -.restart Pending a continueRequest 

startOf SubTrans = (NewTrans v extraTrans) a okForTrans 

doingTrans = startOf SubTrans v (activeTrans a ^extraTrans) 

IsInvalidRAM = doingTrans a IsRAM a (Adr 9 v (Adr 8 a Adr 7 ) ) 

IsTestModeWE = doingTrans a IsRAM a IsWrite a Adr 9 

IsTestReg 0 = IsTestModeWE a Adr 3 #write to flash test register - 
bit 1 of word adr 

IsTestRegi = IsTestModeWE a Adr 4 #write to flash test register - 
bit 2 of word adr 

MRUTestWE = IsTestRego v IsTestRegi 
IsPageErase = AccessMode 4 

IsDeviceErase = AccessMode 5 v (IsTestModeWE a (Adr 8 _ 2 = 0001000)) # 
bit 9 not req 

IsErase = IsDeviceErase v IsPageErase 

MRURAMSel = IsRAM a -.MRUTestWE a -.IsDeviceErase 
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IsInfBlock = (PMEn a ( IsDeviceErase v IsRead) ) v 
(-iPMEn a infoBlockSel a 

(IsDeviceErase v (IsFlash a (Adr n . 7 = 0) a -i (Adr 6 a 
doShadows) ) ) ) 

# Which element (byte or nybble) are we up to xferring? 
If (NewTrans) 

toXfer = 0 
Else 

toXfer = nextToXfer 
Endlf 

# Form the address that goes to the outside world 
If (IsFlash a noShadows) 

byteCount = toXfer^o 

MRUAdr 12 = hiFlashAdr # upper or lower block of 4Kbytes of flash 
MRUAdrn-2 = Adr n _ 2 # word # 

MRUAdr^o = (Adr^o a (-,Is32Bit I -iIs32Bit ) ) v byteCount # byte 
Else 

byteCount = toXfer 2 -i 
MRUAdr 12 - 3 = Adrn-2 # word # 

MRUAdr 2 -i = (Adr^o a (-.Is32Bit I ->Is32Bit ) ) v byteCount # byte 
MRUAdr 0 = toXfer 0 #nybble 
Endlf 

# Assuming a write, are we allowed to write to this address? 
writeEn = SelectBit [WriteMask, ( (MRUAdr 2 a doShadows) I MRUAdri_ 0 ) ] # 
mux: 1 from 8 

# Generate the 4-bit mask to be used for XORing during CPU access 
to flash 

baseMask = SelectNybble ( PM320ut , MRUAdr 2 . 0 ) # mux selects 4 bits of 
32 

If (PMEn) 

theMask = 0 
Else 

theMask = baseMask # we only use mask for CPU accesses to flash 
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Endlf 



# Select a byte (and nybble) from the data for writes 

baseByte = SelectByte [ReqDataOut , byteCount] # mux: 8 bits from 
32 

baseNybble = SelectNybble [baseByte, toXfer 0 ] # mux: 4 bits from 8 
outNybble = baseNybble ® theMask # only used when nybble writing 

# Generate the data on the output lines (doesn't matter for reads 
or erasures) 

MRUDataOut 31 - 8 = ReqDataOut 31 - 8 # effectively don't care for flash 
writes 

If (doShadows) 

MRUDataOut 7 = -.outNybble 3 

MRUDataOut 6 = outNybble 3 

MRUDataOut 5 = -.outNybble 2 

MRUDataOut 4 = outNybble 2 

MRUDataOut 3 = -nOutNybblei 

MRUDataOut 2 = outNybblei 

MRUDataOut! = -.outNybble 0 

MRUDataOuto = outNybble 0 
Else 

MRUDataOut 7 . 0 = baseByte 
Endlf 

# Setup MRUMode 

allowTrans - IsRAM v IsRead v (IsWrite a writeEn) v IsErase 
If (doingTrans) 

MRUMode 2 = IsInfBlock 

MRUMode! = IsErase v IsTestRegi 

MRUMode 0 = IsDeviceErase v (-ilsWrite a -iIsPageErase ) v 
IsTestReg 0 

MRUNewTrans = startOf SubTrans a allowTrans a 

(-•IsInvalidRAM v MRUTestWE v IsDeviceErase) 

Else 

MRUMode 2 - 0 = 001 # read (safe) 
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MRUNewTrans = 0 
Endlf 

# Generate the effective nybble read from flash (this may not be 
used) . 

# When there is a shadowFault (non-erased memory and invalid 
shadows) we consider 

# it a bad read when an 8-bit read, or when writeMask 0 is 0. 

# Note: we always substitute the upper nybble of WriteMask for the 
non-valid data, 

# but only flag a read error if WriteMask 0 is also 1. When the 
data is erased, 

# we return 0 regardless of WriteMask 0 . 
f inishedTrans = doingTrans a MAURdy 

f inishedFlashSubTrans = f inishedTrans a IsFlash a -iIsErase 
isWrittenFlash = ( FlashData 7 - 0 * 11111111) # flash is erased to 
all Is 

If (isWrittenFlash a ( (FlashData 7 , 5 , 3 , 1 0 FlashData 6 , 4 , 2 , 0 ) * 1111) ) 
inNybble 3 - 0 = WriteMask 7 _ 4 

badRead = f inishedFlashSubTrans a IsRead a (Is8Bit v 
-iWriteMask 0 ) a doShadows 
Else 

inNybble 3 , 2 ,i,o = (theMask 3/2 ,i,o © FlashData 6 , 4f 2 , o ) a isWrittenFlash 
badRead = 0 
Endlf 

# Present the resultant data to the outside world 

MaskTheData = IsInvalidRAM v badRead v (badUntilRestart a -iIsRAM) 
NoData = IsErase v IsWrite v -idoingTrans 
If (NoData v MaskTheData) 

MRUData 0 = IsInvalidRAM a illChip 

MRUData 4 _i = retryCount a (IsInvalidRAM a Adr 2 ) # mask all 4 
count bits 

MRUData 3 i_ 5 = 0 # also ensures a read that is bad returns 0 
Elself (IsRAM) 
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MRUData 3 i- 2 4 = SelectByte [RAMData, (Adr^o v Is32Bit | Is32Bit ) ] # 
mux: 8 from 32 

MRUData 23 -o = RAMData 23 -o # lsbs remain unchanged from RAM 
Else If (cioShadows) 

MRUData 31 _ 28 - inNybble 

MRUData 27 -o = buff 27 - 0 
Else 

MRUData 31 . 24 = FlashData 
MRUData 23 . 0 = buff 27 _ 4 
Endlf 

# Shift in the data for the good reads - either 4 or 8 bits 
(writes = don't care) 

If ( f inishedFlashSubTrans a -ibadRead) 
buff 3 _ 0 <- buff 7 _ 4 # shift right 4 bits 
If (doShadows) 

buff 23 _ 4 <- buff 27 _ 8 # shift right 4 

bits 

buff 27 _ 24 <— inNybble 
Else 

buff 19 . 4 <- buff 2 7-i2 # shift right 8 bits, buff 3 _ 0 is don't care 
buff 27 - 20 <- FlashData 
Endlf 
Endlf 

# Determine whether or not we need a new sub-transaction. We only 
need one if: 

# * there hasn't been a transition to IdleMode during this 
transaction 

# * we're doing 8 bit reads that are shadowed 

# * we're doing 32 bit reads and we've done less than 4 or 8 (sh 
vs non-sh) 

# * we got a bad read from flash and we need to retry the read 
(jic was a glitch) 

moreAdrsToGo = (-itoXfer 0 a ( (Is8Bit a doShadows) v Is32Bit)) v 

(itoXferi a Is32Bit) v (-!toXfer 2 a Is32Bit a doShadows) 
needToRetryRead = badRead a (-iretryStarted v (retryCount * 1111)) 
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extraTrans_in = f inishedFlashSubTrans a (moreAdrsToGo v 
needToRetryRead) 

a okForTrans 

nextToXfer <- toXfer + ( f inishedFlashSubTrans a (IsWrite v 
-ineedToRetryRead) ) 

# generate our rdy signal and state values for next cycle 
MRURdy = -.doingTrans v (doingTrans a MAURdy a ->extraTrans_in) 
extraTrans <- extraTrans_in 

activeTrans <- -.MRURdy # all complete only when MRURdy is set 

# Take account of bad reads 

triedEnough = badRead a retryStarted a (retryCount = 1111) 
If (MAURdy) 

If (IsTestModeWE a (Adr 5 _ 2 = 0000)) # capture writes to local 
regs 

illChip <r- 0 
retryCount <— 0 
Else 

illChip <- illChip v triedEnough 
If (badRead) 

retryCount (retryCount a retryStarted) + 1 # AND all 4 

bits 

retryStarted <— 1 
Else 

retryStarted <- 0 # clear flag so will be ok for the next 

read 

Endlf 
Endlf 
Endlf 

# Ensure that we won't have problems restarting a program 

If (MRURdy a -.okForTrans) # note MRURdy (may not be running a 
transaction ! ) 

shadowsOf f , hiFlashAdr, inf oBlockSel, restart Pending, 

badUntilRestart <— 0 
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Else 

badUntilRestart <- badUntilRestart v triedEnough 
If (doingTrans a -iContinueRequest ) 

restartPending ^ 1 # record for later use 
5 Endlf 

If (IsTestModeWE a Adr 2 ) # the other writes are taken care of by 
the MAU 

shadowsOff <— ReqDataOut 0 
hiFlashAdr <— ReqDataOut]. 
10 infoBlockSel <— ReqDataOut 2 

Endlf 
Endlf 

19 Memory Access Unit 

The Memory Access Unit (MAU) takes memory access control signals and turns them into RAM 
1 5 accesses and flash access strobed signals with appropriate duration. 

A new transaction is given by MRUNewTrans. The address to be read from or written to is on MRUAdr, 
which is a nybble-based address. The MRUAdr (13-bits) is used as-is for Flash addressing. When 
MRURAMSel = 1 , then the RAM address (RAMAdr) is taken from bits 9-3 of MRUAdr. The data to be 
written is on MRUData. 

20 The return value MAURdy is set when the MAU is capable of receiving a new transaction the 

following cycle. Thus MAURdy will be 1 during the final cycle of a flash or ram access, and should be 
1 when the MAU is idle. MAURdy should only be 0 during startup or when a transaction has yet to 
finish. 

When MRURAMSel = 1, the access is to RAM, and MRUMode has the following interpretation: 
25 Table 384. Interpretation of MRUMode 10 for ram accesses 



bits 


action 


KXO 


doWrite 


xx1 


doRead 



When MRURAMSel = o, the access is to flash. If MRUTesWVE = o, then the access is to regular flash memory, as given by MRUMode; 

11 

Table 385. Interpretation of MRUMode for regular flash accesses 
MRUMode 2 -i is ignored for RAM accesses 

MRUMode 2 can be directly interpreted by the MAU as the IFREN signal required for embedded flash block 
SFC008 08B9HE 
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bitsl-0 


action when MRUMode2=0 


action when MRUMode2=1 


no 


Hn\A/ rito /main mamnn t\ 

uuvviiit; ^inciin r iicriiury ) 


oovvrne vimo diock; 


01 


doRead (main memory) 


doRead (info block) 


10 


doErasePage (main 
memory) 


doErasePage (info block) 


11 


doEraseDevice (main 
memory) 


doEraseDevice (both 
blocks) 



If MRUTestWE is 1 , then MRUMode2 will also be 0, and the access is to a flash test 
register, as given by MRUMode: 
5 Table 386. Interpretation of MRUMode for flash test register write accesses 



bits 1 * 


action 


XX 1 


If (MRUData 3 = 0), tie the flash IP test register to its reset state 

If (MRUData 3 = 1 ), take the flash IP test register out of reset state, and 

write MRUDatae-4 to the 5-bit flash test register within the flash IP 

(SFC008_08B9_HE) 


x1x 


Write MRUData 28 -9 to the internal 20-bit alternate-counter-source register 
flashTime, and MRUData 29 to the corresponding 1-bit test register 
timerSel. 



1 9. 1 Implementation 

The MAU consists of logic that calculates MAURdy, and additional logic that produces the various 
1 0 strobed signals according to the TSMC Flash memory SFC0008_08B9_HE; refer to this datasheet 
[4] for detailed timing diagrams. Both main memory and information blocks can be accessed in the 
Flash. The Flash test modes are also supported as described in [5] and general application 
information is given in [6]. 

The MAU can be considered to be a RAM control block and a flash control block, with appropriate 
1 5 action selected by MRURAMSel. For all modes except read, the Flash requires wait states (which are 
implemented with a single counter) during which it is possible to access the RAM. Only 1 
transaction may be pending while waiting for the wait states to expire. Multiple bytes may be written 
to Flash without exiting the write mode. 



MRUMode 2 will always be 0 when MRUTestWE = 1. 
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I 
I 

! 

The MAU ensures that only valid control sequences meeting the timing requirements of the Flash 
memory are provided. A write time-out is included which ensures the Flash cannot be left in write 
mode indefinitely; this is used when the Flash is programmed via the IO Unit to ensure the X 
address does not change while in write mode. Otherwise, other units should ensure that when 
5 writing bytes to Flash, the X address does not change. The X address is held constant by the MAU 
during write and page erase modes to protect the Flash. If an X address change is detected by the 
MAU during a Flash write sequence, it will exit write mode allowing the X address to change and re- 
enter write mode. Thus, the data will still be written to Flash but it will take longer. 
When either the Flash or RAM is not being used, the MAU sets the control signals to put the 
1 0 particular memory type into standby to minimise power consumption. 

The MAU assumes no new transactions can start while one is in progress and all inputs must 
remain constant until MAU is ready. 

1 9.2 Flash test mode 

MAU also enables the Flash test mode register to be programmed which allows various production 
1 5 tests to be carried out. If MRUTestWE = 1 , transactions are directed towards the test mode register. 
Most of the tests use the same control sequences that are used for normal operation except that 
one time value needs to be changed. This is provided by the flashTime register that can be written to 
by the CPU allowing the timer to be set to a range of values up to more than 1 second. A special 
control sequence is generated when the test mode register is set to 0x1 E and is initiated by writing 
20 to the Flash. 

Note that on reset, timeSel and flashTime are both cleared to 0. The 5-bit flash test register within the 
TSMC flash IP is also reset by setting TMR =1 . When MRUTestWE = 1, any open write sequence is 
closed even if the write is not to the 5-bit flash test register within the TSMC flash IP. 

19.3 Flash power failure protection 

25 Power could fail at any time; the most serious consequence would be if this occurred during writing 
to the Flash and data became corrupted in another location to that being written to. The MAU will 
protect the Flash by switching off the charge pump (high voltage supply used for programming and 
erasing) as soon as the power starts to fail. After a time delay of about 5jis (programmable), to 
allow the discharge of the charge pump, the QA chip will be reset whether or not the power supply 

30 recovers. 

1 9.4 Flash access state machine 

19.5 Interface 

Table 387. MAU interface description 

35 



Signal name 


I/O 


Description 


Clk 


In 


System clock. 
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RstL 


In 


System reset (active low). 


MAURAMEn 


In 


Flag indicating whether the external user needs 
access to the RAM at a gross level (e.g. the CPU is 
active and therefore may want RAM access). 1 = 
wants access available, 0 = don't want. 


MRUNewTrans 


In 


Flag indicating MRU wishes to start a new 
transaction. May only be asserted (= 1 ) when 

& M A 1 1 ^\ _J ^ All' all At 111 ■ * 

MAURdy = 1 . All inputs below must be held constant 
until MAU is ready. 


ft m i~\ i ■ i~\ a it a f> _ i 

MRURAMSel 


In 


1 = RAM, 0 = Flash. 


ft M I"** 1 I ft M _l A A 

MRUMode2-0 


In 


Type of transaction to be performed. 


MRUAdrl 2-0 


In 


Memory address from the MRU. 


MRUDataOut31- 
0 


In 


Data used to control and set test modes and timing. 


MRUTestWE 


In 


Flag indicating test mode transactions. 


PwrFailing 


In 


Flag indicating possible power failure in progress. 


MAURdy 


Out 


The MAU is ready when MAURdy = 1 . It is always 
set for RAM transactions and held low during Flash 
wait states. 


RAMOutEn 


Out 


0 = enable the RAM to read or write this cycle (i.e. 
active low) 1 = disable the RAM this cycle (saves 
power, memory is intact) 


RAM WE 


Out 


RAM write when RAMWE = 0 (Artisan Synchronous 
SRAM). 


MemClk 


Out 


Inverted system clock to the RAM (required to meet 
timing). 


FlashCtrl8-0 


Out 


Control signals to the Flash. 

IFREN = information block enable, not used always 

= 0 

XE = X address enable 

YE = Y address enable 

SE = sense amplifier enable (read only) 

OE = output enable (read only), hi-Z when OE = 0 

PROG = program (write bytes) 

NVSTR = enables all write and erase modes 

ERASE = page erase mode 
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IVIMO 1 — ITIaob cidSc lllOQc 


TMR 


Out 


TMR = Register reset for test mode 


RAMAdr6-0 


Out 


RAM address in the range 0 to 95. 


FlashAdr12-0 


Out 


Flash address, full range. 


MAURstOutL 


Out 


Activates the global reset, RstL 



19.6 Calculation of timer values 

Set and calculate timer initialisation values based on Flash data sheet values, clock period and 
clock range. 

# Note: Flash data sheet gives minimum timings 

# Delays greater than 1 clock cycle 



clock_per 




100 


# 


ns 






Flash_Tnvs 




7500 


# 


ns 






Flash_Tnvh 




7500 


# 


ns 






Flash_Tnvhl 




150 


# 


us 






Flash_Tpgs 




15 








# us 


Flash_Tpgh 




100 


# 


ns 






Flash_Tprog 




30 


# 


us 






Flash_Tads 




100 


# 


ns 






Flash_Tadh 




30 


# 


us 


# 


Byte write timeout 


Flash Trcv 




1500 


# 


ns 






Flash Thv 




6 


# 


ms 


# 


Not currently used 


Flash_Terase 




30 


# 


ms 






Flash_Tme 




300 


# 


ms 







# Derive maximum counts (-1 since state machine is synchronous) 

FLASH_NVS = Flash_Tnvs/clock_per - 1 

FLASH_NVH = Flash_Tnvh/clock_per - 1 

FLASH_NVH1 = Flash_Tnvhl* 1000/clock_per - 1 

FLAS H_PGS = Flash_Tpgs*1000/clock_per - 1 

FLASH_PGH = Flash_Tpgh/clock_per - 1 

FLASH_PROG = Flash_Tprog* 1 0 00 /clock_per - 1 

FLASH_ADS = Flash_Tads /clock_per - 1 

FLASH_ADH = FlashJTadh* 1 0 00 /clock_per - 1 

FLASH_ADH_AND_WRITE_PGH = FLASH__ADH + FLASH_PGH + 1 # note is 
FLASH_RCV = Flash_Trcv/clock_per - 1 
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FLASH_HV = Flash_Thv*1000000/clock_per - 1 
FLASH_ERASE = FlashJTerase* 1000000/clock_per - 1 
FLASH_ME = Flash_Tme*1000000/clock_per - 1 



5 count_size = 24 # Number of bits in timer counter (newCount) 

determined by Tme 

19.7 Defaults 

Defaults to use when no action is specified. 

FlashTransPendingSet = 0 
10 FlashTransPendingReset = 0 

TMRSet = 0 

TMRRst - 0 

STLESet - 0 

STLERst = 0 
15 TestTimeEn = 0 

IFREN = FlashXadr 7 

XE = 0 

YE - 0 

SE = 0 

20 OE = 0 

PROG = 0 

NVSTR = 0 

ERASE = 0 

MAS1 = 0 
25 MAURs tOutL = 1 



If (accessCount ^ 0) 

newCount = accessCount - 1 # decrement unless instructed 
otherwise 
30 Else 

newCount = 0 
Endlf 

19.8 Reset 

Initialise state and counter registers. 

35 # asynchronous reset (active low) 

state <— idle 
accessCount <— 1 
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countZ <— 0 
XadrReg <— 0 
FlashTransPending <— 0 
TestTime <- 0 
TMR <- 1 
STLEFlag <- 0 

19.9 State machine 

The state machine generates sequences of timed waveforms to control the operation of the Flash 
memory. 

idle 

FlashTransPendingReset = 1 

If (somethingToDo) # Flash starting conditions 
If (MRUTestWE) 

nextState = TMO 
Else 

Switch (MRUModeint ) 
Case doWrite: 

nextState =writeNVS 

newCount = FLASH_NVS 
Case doRead: 

YE = 1 

SE = 1 

OE = 1 

XE = 1 

nextState = idle 
Case doErasePage: 

nextState =pageErase 

newCount = FLASH_NVS 
Case doEraseDevice: 

nextState =massErase 

newCount = FLASH_NVS 
EndSwitch 
Endlf 
Endlf 

19.9.1 Flash page erase 

The following pseducocode illustrates the Flash page erase sequence. 
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pageErase 
ERASE = 1 
XE = 1 

If (-iPwrFailing) 
If (countZ) 

newCount = FLAS H_E RAS E 
nextState = pageEraseERASE 
Endlf 
Else 

newCount = TestTimei 9 - 0 
nextState =Helpl 
Endlf 

pageEraseERASE 
ERASE = 1 
NVSTR = 1 
XE = 1 

If (-iPwrFailing) 
If (countZ) 

newCount = FLASH_NVH 
nextState = pageEraseNVH 
Endlf 
Else 

newCount = TestTime 19 _ 0 
nextState =Helpl 
Endlf 

pageEraseNVH 
NVSTR = 1 
XE = 1 

If (-.PwrFailing) 
If (countZ) 

newCount = FLASH_RCV 
nextState = RCVPM 
Endlf 
Else 

newCount = TestTimei 9 _ 0 
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nextState =Helpl 
Endlf 

RCVPM 

If ( count Z) 

nextState = idle # exit 

Endlf 
Flash mass erase 

The following pseducocode illustrates the Flash mass erase sequence. 
massErase 

MAS1 = 1 

ERASE = 1 

XE. = 1 

If (countZ) 

If (-.TestTime 2 o) 

newCount = FLASH_ME 
Else 

newCount = TestTimei 9 - 0 I 0000 
Endlf 
nextState 
Endlf 

massEraseME 
MAS1 = 1 
ERASE = 1 
NVSTR = 1 
XE = 1 
If (countZ) 
newCount 
nextState 
Endlf 

massEraseNVHl 
MAS1 = 1 
NVSTR = 1 
XE = 1 
If (countZ) 
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- massEraseME 



FLASH_NVH1 
= massEraseNVHl 



newCount = FLASH_RCV 
nextState = RCVPM 
Endlf 
1 9.9.3 Flash byte write 
5 The following pseducocode illustrates the Flash byte write sequence. 

writeNVS 
PROG = 1 
XE = 1 

If (-iPwrFailing) 
10 If (countZ) 

If (— iSTLEFlag) 

newCount = FLASH_PGS 
nextState =writePGS 
Else 

15 newCount = TestTime 19 _ 0 I 0000 

nextState = STLE0 
Endlf 
Endlf 
Else 

20 newCount = TestTime 19 _ 0 

nextState = Helpl 
Endlf 

writePGS 
25 PROG = 1 

NVSTR = 1 
XE = 1 

If (-.PwrFailing) 
If ( count Z) 
30 newCount = FLASH_ADS 

nextState =writeADS 
Endlf 
Else 

newCount = TestTime 19 - 0 
35 nextState = Helpl 

Endlf 
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writeADS # Add Tads to Tpgs 
PROG = 1 
NVSTR = 1 
XE = 1 

FlashTransPendingReset = 1 
If (-iPwrFailing) 
If (countZ) 

If (-iTestTime 20 ) 

newCount = FLASH_PROG 
Else 

newCount = TestTime 19 _ 0 I 0000 
Endlf 

nextState =writePROG 
Endlf 
Else 

newCount = TestTimei 9 _ 0 
nextState =Helpl 
Endlf 

writePROG 
PROG = 1 
NVSTR = 1 
YE = 1 
XE = 1 

If (-iPwrFailing) 
If ( count Z) 

newCount = FLASH_ADH_AND_WRITE 
nextState =writeADH 
Endlf 
Else 

newCount = TestTime 19 - 0 
nextState = Help2 
Endlf 

writeADH 
PROG = 1 
NVSTR = 1 
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XE = 1 

FlashTransPendingSet = somethingToDo 
If (-.PwrFailing) 

If (-.FlashNewTrans) 
5 If (countZ) — Gracefull exit after timeout 

newCount = FLASH_NVH 
nextState = writeNVH 
Endlf 

Else # — Do something as there is a new transaction 
10 If ( (MRUModeint = doWrite) a (-.XadrCh) ) 

newCount = FLASH_ADS — Write another byte 
nextState =writeADS 
Else 

newCount = FLASH_NVH Exit as new trans is not Flash 

15 write 

nextState = writeNVH 
Endlf 
Endlf 
Else 

20 newCount = TestTimei 9 - 0 

nextState =Helpl 
Endlf 

writeNVH 
25 NVSTR « 1 

XE = 1 

FlashTransPendingSet = somethingToDo 
If (-.PwrFailing) 
If (countZ) 
30 newCount = FLASH_RCV 

nextState = RCV 
Endlf 
Else 

newCount = TestTimei 9 - 0 
35 nextState =Helpl 

Endlf 
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RCV # wait til we're allowed to do another transaction 

FlashTransPendingSet = somethingToDo 
If (countZ) 

nextState = idle 
Endlf 
Test Mode sequence 

The following pseducocode illustrates the test mode sequence. 
TMO # Needed this due to delay on TMR 
IFREN = 0 

nextState = idle # default 
If ( MRUModeintx) 
TestTimeEn = 1 
Endlf 

If (MRUModeinto) 

If (-.MRUDataOut 3 ) 
TMRSet = 1 

STLERst = 1 # Reset flag as leaving test mode 
Else 

If (MRUDataOut 8 _ 4 = 11110) 

STLESet = 1 
Else 

STLERst = 1 
Endlf 

TMRRst = 1 

nextState = TM1 # Will get priority 
Endlf 
Endlf 

TM1 

IFREN = 0 
nextState = TM2 

TM2 

NVSTR = 1 
SE = 1 
IFREN = 0 
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nextState = TM3 

TM3 

NVSTR = 1 
SE = 1 

MAS1 = MRUDataOut 4 
IFREN = MRUDataOut 5 
XE = MRUDataOut 6 
YE = MRUDataOut 7 
ERASE = MRUDataOut 8 
TMRSet = 1 
nextState = TM4 

TM4 

NVSTR = 1 
SE = 1 

MAS1 - MRUDataOut 4 
IFREN = MRUDataOut 5 
XE = MRUDataOut 6 
YE = MRUDataOut 7 
ERASE = MRUDataOut 8 
TMRRst - 1 
nextState = TM5 

TM5 

NVSTR = 1 
SE = 1 

MAS1 = MRUDataOut 4 
IFREN = MRUDataOut 5 
XE = MRUDataOut 6 
YE = MRUDataOut 7 
ERASE = MRUDataOutg 
nextState = TM6 

TM6 

NVSTR = 1 
SE = 1 



nextState = idle 
19.9.5 Reverse tunneling and thin oxide leak test 

The following pseducocode shows the reverse tunneling and thin oxide leak test 
sequence. 

5 STLEO 

XE = 1 
PROG = 1 
NVSTR = 1 
If (countZ) 
10 newCount = FLASHJNfVH 

nextState = STLE1 
Endlf 



15 



20 



STLEl 

XE = 1 
NVSTR - 1 
If (countZ) 
newCount = 
nextState 
Endlf 



FLASH_RCV 
= STLE2 



STLE2 

If (countZ) 

nextState = idle 
25 Endlf 

19.9.6 Emergency instructions 

The following pseducocode shows the states used for emergency situations such 
as when power is failing. 
Helpl # MAURdy -> 0 to hold MAU inputs constant, if not too late 

30 xe = i 

If (countZ) 

nextState = Goodbye 
Endlf 



35 Help2 # MAURdy -> 0 to hold MAU inputs constant, if not too late 

XE = 1 
YE = 1 
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If (countZ) 
nextState 
Endlf 



= Goodbye 



Goodbye 

XE = 1 # Prevents Flash timing violation 
MAURstOutL = 0 # Reset whole chip whether power fails 
# nothing else to do or recovers 

Concurrent logic 

accessCount <— newCount # update accessCount every cycle 
count Z <— (newCount = 0) 

XadrReg <- FlashXAdr # store the previous X address 
state <— nextState 

If (FlashTransPendingReset ) 

FlashTransPending <- 0 # Reset flag (has priority) 
Else 

If (FlashTransPendingSet ) 

FlashTransPending <- 1 # Set flag 
Endlf 
Endlf 

If (TestTimeEn) 

TestTime <r- MRUDataOut 2 9-9 
Endlf 

If (TMRSet) — SRFF for TMR 

TMR <- 1 
Else 

If (TMRRst) 
TMR 0 

Endlf 
Endlf 

If (STLERst) — SRFF for STLE tests 
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STLEFlag <- 0 
Else 

If (STLESet) 

STLEFlag <- 1 

Endlf 
Endlf 

FlashNewTrans = MRUNewTrans a {— iMRURAMSel ) 

RAMNewTrans = MRUNewTrans a MRURAMSel 

somethingToDo = FlashTransPending v FlashNewTrans 

quickCmd = (MRUModeint = doRead) a — iMRUTestWE 

FlashRdy = ( (state = idle) a (-iSomethingToDo v quickCmd) ) 

v (((state = writeADH) 

v (state = writeNVH) 

v (state = writeRCV) ) a (-.FlashTransPendingSet ) ) 
v ((state - TMO) a (nextState = idle)) 
v (state = TM6) 

If (MRURamSel) 

MAURdy = 1 # Always ready for RAM 
Else 

MAURdy = FlashRdy 
Endlf 

IandX = MRUMode 2 I MRUAdr 12 - 6 

FlashXAdr = IandX When ( (-.XE) v (SE a OE) ) Else XadrReg 
FlashAdr = FlashXAdr I MRUAdr 5 _ 0 # Merge X and Y addresses 
XadrCh = 1 When ((XadrReg /= IandX) a XE a(-iSE) a (-.OE 

a FlashNewTrans ) Else 0 

# Xadr change 

MRUModeint = MRUModei_ 0 # Backwards compatability 

RAMAdr = MRUAdr 9 _ 3 # maximum address = 95 , responsibility o 
MRU for valid adr 

RAMWE = MRUModeinto 

RAMOutEn = -.RAMNewTrans # turn off RAM if not using it 
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FlashCtrl (0) 




IFREN 


FlashCtrl (1) 


= 


XE 


FlashCtrl (2) 


= 


YE 


t lasnLtri ( 




CI? 


FlashCtrl (4) 


_ 


OE 


FlashCtrl (5) 




PROG 


FlashCtrl (6) 




NVSTR 


FlashCtrl (7) 




ERASE 


FlashCtrl (8) 




MAS1 


MemClk 




-.Clk 



# Memory clock 



20 Analogue unit 

This section specifies the mandatory blocks of Section 11.1 on page 965 in a way which allows 
1 5 some freedom in the detailed implementation. 

Circuits need to operate over the temperature range -40°C to +125°C. 

The unit provides power on reset, protection of the Flash memory against erroneous writes during 
power down (in conjunction with the MAU) and the system clock SysClk. 
20.1 Voltage budget 

20 The table below shows the key thresholds for V DD which define the requirements for power on reset 
and normal operation. 
Table 388. V DD limits 



VDD parameter 


Description 


Voltage 


VDDFTmax 


Flash test maximum 


3.6 13 


VDDFTtyp 


Flash test typical 


3.3 


VDDFTmin 


Flash test minimum 


3.0 


VDDmax 


Normal operation maximum (typ + 
10%) 


2.75 14 


VDDtyp 


Normal operation typical 


2.5 


VDDmin 


Normal operation minimum (typ - 5%) 


2.375 


VDDPORmax 


Power on reset maximum 


2.0 1b 



The voltage VDDFT may only be applied for the times specified in the TSMC Flash memory test document. 
Voltage regulators used to derive VDD will typically have symmetric tolerance lim its 
The minimum allowable voltage for Flash memory operation. 
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20.2 VOLTAGE REFERENCE 

This circuit generates a stable voltage that is approximately independent of PVT (process, voltage, 
temperature) and will typically be implemented as a bandgap. Usually, a startup circuit is required to 
avoid the stable V^ = 0 condition. The design should aim to minimise the additional voltage above 
5 Vbg required for the circuit to operate. An additional output, BGOn, will be provided and asserted 
when the bandgap has started and indicates to other blocks that the output voltage is stable and 
may be used. 

Table 389. Bandgap target performance 



Parameter 


Conditions 


Min 


Typ 


Max 


Units 


Vbg 1 * 


typical 


1.2 


1.23 


1.26 


V 


IDD 


typical 




50 




HA 


Vstart 


worst case 


1.6 






V 


lout 








10 


nA 


Vtemp 






+0.1 




mV/oC 



20.3 Power detection unit 

Only under voltage detection will be described and is required to provide two outputs: 
underL controls the power on reset; and 
PwrFailing indicates possible failure of the power supply. 
1 5 Both signals are derived by comparing scaled versions of V DD against the reference voltage V^. 

20.3.1 V D d monotonicity 

The rising and falling edges of V DD (from the external power supply) shall be monotonic in order to 
guarantee correct operation of power on reset and power failing detection. Random noise may be 
present but should have a peak to peak amplitude of less than the hysteresis of the comparators 
20 used for detection in the PDU. 

20.3.2 Under Voltage Detection Unit 

The underL signal generates the global reset to the logic which should be de-asserted when the 
supply voltage is high enough for the logic and analogue circuits to operate. Since the logic reset is 
asynchronous, it is not necessary to ensure the clock is active before releasing the reset or to 
25 include any delay. 

The QA chip logic will start immediately the power on reset is released so this should only be done 
when the conditions of supply voltage and clock frequency are within limits for the correct operation 
of the logic. 



Over PVT, not including offsets 
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The power on reset signal shall not be triggered by narrow spikes (< 100ns) on the power supply. 
Some immunity should be provided to power supply glitches although since the QA chip may be 
under attack, any reset delay should be kept short. The unit should not be triggered by logic 
dynamic current spikes resulting in short voltage spikes due to bond wire and package inductance. 
5 On the rising edge of V DD , the maximum threshold for de-asserting the signal shall be when V DD > 
VoDmirv On the falling edge of V DD> the minimum threshold for asserting the signal shall be V DD < 

VoDPORmax- 

The reset signal must be held low long enough (T pwmin )to ensure all flip-flops are reset. The 
standard cell data sheet [7] gives a figure of 0.73ns for the minimum width of the reset pulse for all 
1 0 flip-flop types. 

2 bits of trimming (trim^) will be provided to take up all of the error in the bandgap voltage. This will 
only affect the assertion of the reset during power down since the power on default setting must be 
used during power up. 

Although the reference voltage cannot be directly measured, it is compared against V DD in the PDU. 

1 5 The state of the power on reset signal can be inferred by trying to communicate through the serial 
bus with the chip. By polling the chip and slowly increasing V D d, a point will be reached where the 
power on reset is released allowing the serial bus to operate; this voltage should be recorded. As 
V D D is lowered, it will cross the threshold which asserts the reset signal. The power on default is set 
to the lowest voltage that can be trimmed (which gives the maximum hysterisis). This voltage 

20 should be recorded (or it may be sufficient to estimate it from the reset release voltage recorded 
above). V DD is then increased above the reset release threshold and the PDU trim adjusted to the 
setting the closest to V DD p 0 Rmax- V DD should then be lowered and the threshold at which the reset is 
re-asserted confirmed. 

Table 390. Power on reset target performance 

25 



Parameter 


Conditions 


Min 


Typ 


Max 


Units 


Vthrup 


T = 27oC 


2.0 




2.375 


V 


Vthrdn 


T = 27oC 


2.0 




2.1 


V 


Vhystmin 






16 




mV 


IDD 






5 




MA 


Tspike 






100 




ns 


Vminr 






0.5 




V 


Tpwmin 




1 






ns 



Power on reset behaviour 

The signal PwrFailing will be used to protect the Flash memory by turning off the charge pump during 
a write or page erase if the supply voltage drops below a certain threshold. The charge pump is 
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expected to take about 5us to discharge. The PwrFailing signal shall be protected against narrow 
spikes (< 100ns) on the power supply. 

The nominal threshold for asserting the signal needs to be in the range V P0 Rmax < V DD p Fty p < V DDmjn 
so is chosen to be asserted when V DD < V DD p Ftyp = V D DPORmax + 200m V. This infers a V DD slew rate 
5 limitation which must be < 200mV/5us to ensure enough time to detect that power is failing before 
the supply drops too low and the reset is activated. This requirement must be met in the application 
by provision of adequate supply decoupling or other means to control the rate of descent of V DD . 
Table 391 . Power failing detection target performance 



Parameter 


Conditions 


Min 


Typ 


Max 


Units 


Vthr 


T = 27oC 


2.1 


2.2 


2.3 


V 1 ' 


Vhyst 






16 




mV 


IDD 






5 




HA 


Tspike 






100 




ns 


Vminr 






0.5 




V 



10 

2 bits of trimming (trim^) will be provided to take up all of the error in the bandgap voltage. 
20.4 Ring oscillator 

SysClk is required to be in the range 7-14 MHz throughout the lifetime of the circuit provided V DD is 
maintained within the range V DDM in < V D d < V DDM ax. The 2:1 range is derived from the programming 
1 5 time requirements of the TSMC Flash memory. If this range is exceeded, the useful lifetime of the 
Flash may be reduced. 

The first version of the QA chip, without physical protection, does not require the addition of random 
jitter to the clock. However, it is recommended that the ring oscillator be designed in such a way as 
to allow for the addition of jitter later on with minimal modification. In this way, the un-trimmed centre 
20 frequency would not be expected to change. 

The initial frequency error must be reduced to remain within the range 10MHz / 1 .41 to 10MHz 
x 1 .41 allowing for variation in: 

voltage 

temperature 
25 • ageing 

added jitter 

errors in frequency measurement and setting accuracy 
The range budget must be partitioned between these variables. 
Figure 41 1 ._ Ring oscillator block diagram 

17 These limits are after trimming and include an allowance for VDD ramping. 
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The above arrangement allows the oscillator centre frequency to be trimmed since the bias current 
of the ring oscillator is controlled by the DAC. SysClk is derived by dividing the oscillator frequency 
by 5 which makes the oscillator smaller and allows the duty cycle of the clock to be better 
controlled. 

5 20.4.1 DAC (programmable current source) 

Using V^, this block sources a current that can be programmed by the Trim signal. 6 of the 
available 8 trim bits will be used (trim 7 _ 2 ) giving a clock adjustment resolution of about 250kHz. The 
range of current should be such that the ring oscillator frequency can be adjusted over a 4 to 1 
range. 

1 0 Table 392. Programmable current source target performance 



Parameter 


Conditions 


Min 


Typ 


Max 


Units 


lout 


Trim7-2 = 0 
Trim7-2 = 32 
Trim7-2 = 63 




5 

12.5 
20 




HA 


Vrefin 






1.23 




V 


Rout 


Trim 7-2 = 63 


2.5 






MQ 



20.4.2 Ring oscillator circuit 

Table 393. Ring oscillator target performance 

15 



Parameter 


Conditions 


Min 


Typ 


Max 


Units 


Fosc 10 




7 


10 


14 


MHz 


IDD 






10 




HA 


Kl 






1 




MHz/nA 


KVDD 






+200 




KHz/V 


KT 






+30 




KHz/oC 


Vstart 




1.5 






V 



K| = control sensitivity, K V dd = V DD sensitivity, K T = temperature sensitivity 

With the figures above, K V dd will give rise to a maximum variation of +50kHz and K T 

to +1 .8MHz over the specified range of V D d and temperature. 



20.4.3 Div5 

20 The ring oscillator will be prescaled by 5 to obtain the nominal 10MHz clock. An asynchronous 
design may be used to save power. Several divided clock duty cycles are obtainable, eg 4:1, 3:2 



Accounting for division by 5 
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etc. To ease timing requirements for the standard cell logic block, the following clock will be 
generated; most flip-flops will operate on the rising edge of the clock allowing negative edge 
clocking to meet memory timing. 
Table 394. Div5 target performance 



Parameter 


Conditions 


Min 


Typ 


Max 


Units 


Fmax 


Vdd = 1 .5V 


100 






MHz 


IDD 






10 




HA I 



20.5 Power on reset 

This block combines the overL (omitted from the current version), underL and MAURstOutL signals to 
provide the global reset. MAURstOutL is delayed by one clock cycle to ensure a reset generated when 
this signal is asserted has at least this duration since the reset deasserts the signal itself. It should 
be noted that the register, with active low reset RN, is the only one in the QA chip not connected to 
RstL 

[4] TSMC, Oct 1, 2000, SFC0008_08B9_HE, 8K x 8 Embedded Flash Memory Specification, Rev 
0.1. 

[5] TSMC (design service division), Sep 10, 2001, 0.25um Embedded Flash Test Mode User 
Guide, V0.3. 

[6] TSMC (EmbFlash product marketing), Oct 19, 2001 , 0.25um Application Note, V2.2. 
[7] Artisan Components, Jan 99, Process Perfect Library Databook 2.5-Volt Standard Cells, 
Revl.O. 
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OTHER APPLCATIONS FOR PROTOCOLS AND QA CHIPS 
1 Introduction 

In its preferred form, the QA chip [1] is a programmable 32 bit microprocessor with security features 
(8,000 gates, 3k bits of RAM and 8kbytes of flash memory for program and non-volatile data 
5 storage). It is manufactured in a 0.25 um CMOS process. 

Physically, the chip is mounted in a 5 pin SOT23 plastic package and communicates with external 
circuitry via a two pin serial bus. 

1 0 The QA chip was designed to for authenticating consumable usage and performance upgrades in 
printers and associated hardware. 



Because of its core functionality and programmability the QA chip can also be used in applications 
that differ significantly from its original one. This document seeks to identify some of those areas. 

15 

3 Applications Overview 
Applications include: 
o Regular EEPROM 
o Secure EEPROM 
20 o General purpose MPU with security features 

o Security coprocessor for microprocessor system 

o Security coprocessor for PC (with optional USB connection) 

o Resource dispenser - secure, web based transfer of a variable quantity from "source" to "sink" 
o ID tag 
25 o Security pass inside offices 
o Set top box security 
o Car key 
o Car Petrol 

o Car manufacturer "genuine parts" detection, where the car requires genuine (or authorised) 
30 parts to function. 

o Aeroplane control on motor-control servos to allow secure external control on an aircraft in a 
hijack situation. 

Security device for controlling access to and copying of audio, video, and data (eg, preventing 
unauthorized downloading of music to a device). 

35 
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4 Exemplary Application Descriptions 



4.1 Car Petrol 

Using mechanisms and protocols similar to those described in relation to ink refills, refilling of petrol 
5 can be controlled. An example of a commercial relationship this allows is selling a car at a 
discounted rate, but requiring that the car be refilled at designated service stations. Similarly, 
prevention of unauthorized servicing can be achieved. 

4.2 Car Keys 

1 0 4.2.1 Basic advantages over physical keys 

o Keys and locks can be easily programmed & configured for use 

o Can only be duplicated/reprogrammed by an authorised individual 

o The same key can be used for physical entry/exit and remote (radio-based) entry/exit 

o Inbuilt security features 
1 5 4.2.2 Single key for multiple vehicles 

Useful when a family has more than one car. 

o Can be programmed so any keys fits any car. 

o Fewer number of duplicate keys. 

o Misplacing a key for a particular car - any key for any other car can be used as oppose to 
20 duplicate of the same key. 

4.2.3 Multiple keys for a single vehicle 

4.2.3.1 Same company car being driven by multiple drivers 
o Mileage can be logged per driver e.g. for accounting purposes, 
o Key permissions can be different per driver (e.g. boot/trunk access may be disabled) 
25 4.2.3.2 Same family car being driven by children and parents 

o Time/date restrictions can be applied to (e.g. children's) keys 

o Speeds above a specified limit (and duration of that speed) can be logged for auditing 
purposes (may be less dangerous than actually enforcing a speed limit) 

4.2.4 No problem if key lost 
30 Can easily: 

o make a new key the same as lost one (existing copies of key will still function) 
o reprogram the locks on car (and reprogram all non-lost keys to match) so the lost key will no 
longer function 

4.2.5 NO PROBLEM IF KEY LEFT IN CAR 

35 o Easy to create a one-time-use open-door-only key via roadside assistance based on secret 
password information, driver's license etc (prevents having to break into the car) 
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4.2.6 Car rentals 

• Key can have an expiration date (e.g. some period past the rental end-date) 

4.2.7 Single physical key for all locks in car 

A single physical key can open all locks (door, immobiliser, boot/trunk, glovebox etc.). 
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#define INTERP 1 



#include M srm015.c 



#if INTERP 

module stitch_module { 
#endif 

#include <stdio.h> 
#include <stdlib.h> 
#include <string.h> 
#include "ldata.h" 
#include "func.h" 



#define STITCHJVIAR 0.3 
#define GRID_STEP 0.025 
#define BIN_SIZE 128.0 

typedef enum { LEFT, RIGHT, DONOTKNOW } halves; 
static int bin_size = 0; 
static LCoord stitch_mar = 0; 
static LCoord grid_step = 0; 
#def ine otherSide (s) ( (s==D0NOTKN0W) ? DONOTKNOW : (s==LEFT) ?RIGHT : LEFT) 



#define AND 1 
#define OR 0 
#define NOT 1 
#define ACTUAL 0 



int do_Poly = 1; 
int doJVIetall = 1; 
int do_Metal2 = 1; 
int do_Metal3 = 1; 
int do_Metal4 = 1; 
int do_Contact = 1; 
int do_Glass = 1; 
int do_Vial = 1; 
int do_Via2 = 1; 
int do_Via3 = 1; 
int do_NDif fusion = 1; 
int do_PDif fusion = 1; 
int do_NTie = 1; 
int do_PTie = 1; 
int do_NWell = 1; 
int do_PWell = 1; 
int do_PSelect = 1; 
int do_NSelect = 1; 

void SetupSplitLayers ( ) 

{ 

LDialogltem itemsl [ 11 ] = 
{ 

{ "Poly", "1"}, 

{ "Metall", "1"}, 

{ "Metal2" , "1"}, 

{ "Metal3»», "1"), 
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{ "Metal4" , "1"}, 

{ "Contact", "1"} , 

{ "Glass", "1"}, 

{ "Vial", "1"}, 

{ "Via2", "1"}, 

{ "Via3" , "1"}, 

{ "more . . . ", "1"} 

}; 

LDialogltem items2 [ 8 ] = 
{ 

{ "N Diffusion" , "1"), 

{ "P Diffusion", "1"}, 

{ "NTie", "1"}, 

{ "PTie", "1"}, 

{ "N Well" , "1" } , 

{ "P Well", "1"}, 

{ "P+ Select", "1"}, 

{ "N+ Select", "1"} 

}; 



strcpy (itemsl [0] 


.value, 


do 


Poly ? "1" 




"0") 


* 


strcpy (itemsl [1] 


.value , 


do 


"Metal 1 ? "1 


ii 


: "0"); 


strcpy (itemsl [2] 


.value , 


do 


_Metal2 ? "1 


ii 


: " 0 " ) ; 


strcpy (itemsl [3] 


.value , 


do" 


~Metal3 ? "1 


ti 


: "0"); 


strcpy (itemsl [4] 


.value , 


do" 


*Metal4 ? "1 


n 


: "0"); 


strcpy (itemsl [5] 


.value, 


do" 


"contact ? " 


1" 


: "0"); 


strcpy (itemsl [6] 


.value, 


do" 


"Glass ? "1" 




"0") ; 


strcpy (itemsl [7] 


.value, 


do 


"vial ? "1" 




" 0 " ) 




strcpy (itemsl [8] 


.value, 


do 


_Via2 ? "1" 




"0") 4 




strcpy (itemsl [9] 


. value , 


do" 


"via3 ? "1" 




n 0 « ) 




strcpy (items2 [0] 


.value , 


do" 


NDif fusion 


? 


n ^ ii 


: "0") 


strcpy (items2 [1] 


.value , 


do" 


PDif fusion 


? 


ii ^ it 


: "0") 


strcpy (items2 [2] 


.value, 


do" 


~NTie ? "1" 




ii o i. ) 




strcpy (items2 [3] 


.value, 


do" 


"PTie ? "1" 




ii o ii ) 




strcpy (items2 [4] 


.value, 


do" 


JtfWell ? "1" 




" 0 " ) ; 


strcpy (items2 [5] 


.value , 


do" 


"pwell ? "1" 




" 0 " ) ; 


strcpy (items2 [6] 


.value , 


do" 


~PSelect ? " 


1" 


: "0"); 


strcpy (items2 [7] 


.value, 


do" 


^NSelect ? " 


1" 


: " 0 " ) ; 



if ( LDialog_MultiLineInputBox( "Split layer to process", itemsl, 
11 ) ) // failes with more than 15 objects 

{ 

/* A OK was hit by the user, so get the property value from 
the Dialog_Items buffer*/ 

do_Poly = atoi (itemsl [0] .value) ; 
do__Metall = atoi (itemsl [1] .value) ; 
do_Metal2 = atoi (itemsl [2] .value) ; 
do_Metal3 = atoi (itemsl [3] .value) ; 
do_Metal4 = atoi (itemsl [4] .value) ; 
do_Contact = atoi (itemsl [5] .value) ; 
do_Glass = atoi (itemsl [6] .value) ; 
do_Vial = atoi (itemsl [7] .value); 
do_Via2 = atoi (itemsl [8] .value) ; 
do_Via3 = atoi (itemsl [9] .value) ; 
if ( atoi (itemsl [10] .value) 

&& LDialog_MultiLineInputBox ( "Split layer to 

process", items2, 8 ) ) 

{ 

do_NDif fusion = atoi (items2 [0] .value) ; 
do_PDif fusion = atoi (items 2 [1] .value) ; 
do_NTie = atoi (items2 [2] .value) ; 
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do_PTie = atoi (items2 [3] .value) ; 
do_NWell = atoi (items2 [4] .value) ; 
do_PWell = atoi (items2 [5] .value) ; 
do_PSelect = atoi(items2 [6] .value) ; 
do_NSelect = atoi (items2 [7] .value) ; 



} 

} 



halves whichSideOf Wire (LObject object, LPoint p) 

{ 

LVertex v; 
LPoint s, e; 



DONOTKNOW; 



if ( (v = LObject_GetVertexList (object) ) == NULL ) return 
s = LVertex_Get Point (v) / 

for ( v=LVertex_GetNext (v) ; v != NULL; v=LVertex_GetNext (v) ) 
{ 

e = LVertex_Get Point (v) ; 
if ( s . y ! = e .y ) 

{ 

if ( (s.y <= p.y ScSc p.y <= e.y) | | 
(s.y >= p.y ScSc p.y >= e.y) ) 



{ 



assert( s.x == e.x, "wire is not orothanal " ) ; 
if ( p.x <= s.x ) return LEFT; 
return RIGHT; 



} 
} 

s = e; 

} 

return DONOTKNOW; 



long getSelf SpacingRule (LFile File, char *lname) 
{ 

LDrcRule rule; 
LDesignRuleParam *p, drcp; 

if ( (rule = LDrcRule_Find(File / LSPACING, lname, NULL)) == NULL ) 
{ 

if( (rule = LDrcRule_Find(File, LSPACING, lname, "")) == NULL 



) 

== NULL ) 



{ 

if( (rule = LDrcRule_Find(File, LSPACING, lname, lname)) 



{ 

for( rule = LDrcRule_GetList (File) ; rule != NULL; 
rule = LDrcRule_GetNext (rule) ) 

{ 

assert ( p = LDrcRule_GetParameters ( rule, &drcp) , 

"no drc parameters"); 

if ( p->rule_type == LSPACING && strcmp (lname , p- 

>layerl) == 0 ) 

{ 

if ( p->layer2 == NULL || strcmp (p- 
>layer2,"") = = 0 | | strcmp (p- >layer2 , lname) == 0 ) 

{ 

assert (0, "spacing found by search") / 
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assert (0, p->layer2 == NULL ? "(null)" : 

p->layer2) ; 

break; 

} 

} 

} 

} 

} 

} 

assert ( rule, "no drc found parameters"); 

assert ( p = LDrcRule_GetParameters ( rule, &drcp) , "no drc 
parameters") ; 

return p->distance; 

} 

void deleteTmpLayer (LFile File, LLayer layer) 

{ 

LSelection_DeselectAll () ; 
LSelection_AddAHObjectsOnLayer (layer) ; 
LSelection_Clear ( ) ; 
LLayer_Delete (File, layer) ; 

} 

LStatus generateLayer30p ( LFile File, LCell cell, LLayer copy, 

int not_ll, LLayer 11, int grow_ll, 
int opl, 

int not_12, LLayer 12, int grow_l2 , 
int op2 , 

int not_13, LLayer 13, int grow_13) 



{ 



LDerivedLayerParam dpt; 
LDerivedLayerParam *d; 
char copy_name [64] ; 
char ll__name [64] ; 
char 12_name[64]; 
char I3_name [64] ; 

if (bin size == 0 ) bin size = (int) LFile LocUtoIntU (File , 



BIN SIZE) ; 



d = &dpt; 

d->enable_evaluation = 1 ,- 

d->name = LLayer_GetName (copy , copy_name, 64); 
d->layerl_not_op = not_ll; 

d- >src_layerl = LLayer_GetName (11 , ll_name, 64); 
d - > 1 aye r l_grow_amount = grow_ll; 
d->layerl_bool_layer2 = opl; 
d->layer2_not_op = not_12; 
if (12 != NULL ) 

d->src_layer2 = LLayer_GetName (12 , 12_name, 64); 

else 

d->src_layer2 = ""; 
d->layer2_grow_amount = grow_12; 
d->layer2_bool_layer3 = op2 ; 
d->layer3_not_op = not_13; 
if (13 != NULL ) 

d->src_layer3 = LL aye r_Get Name (13 , 13_name, 64); 

else 

d->src_layer3 = ""; 
d->layer3_grow_amount = grow_13; 



1039 



IsOK( LLayer_SetDerivedParameters (File, copy, d) , "Set derived 

op3 " ) ; 

return ( LCell_GenerateLayersExOO (cell , bin_size, copy, LFALSE, 

LFALSE) ) ; 
} 

#define copyLayer ( File, cell, copy, orig, grow) generateLayer30p ( File, 
cell, copy, \ 

ACTUAL, orig, grow, AND, NOT, NULL, 0, AND, 

NOT, NULL, 0) 

#define generateLayer2op ( File, cell, copy, not_ll, 11, grow_ll, op, not_12, 
12, grow_12) \ 

generateLayer30p ( File, cell, copy, not_ll, 11, grow_ll, op, not_12, 
12, grow_l2, AND, NOT, NULL, 0) 

LRect selectionBbox ( ) 

{ 

LSelection sel; 
LObject obj ; 
LRect bb; 
LRect rect; 

sel = LSelection_GetList ( ) ; 

obj = LSelection_GetObject (sel) ; 

bb = LObject_GetMbb(obj) ; 

for( sel = LSelection_GetNext (sel) ; sel != NULL; 
sel = LSelection_GetNext (sel) ) 

{ 

obj = LSelection_GetObject (sel) ; 

rect = LObject_GetMbb (obj ) ; 

if ( rect.yO < bb.yO ) bb.yO - rect.yO; 

if ( rect.yl > bb.yl ) bb.yl = rect.yl; 

if ( rect.xO < bb.xO ) bb.xO = rect.xO; 

if ( rect .xl > bb.xl ) bb.xl = rect.xl; 

} 

return bb; 

} 

LLayer createLayer ( LFile File, LLayer after, char *new_name) 

{ 

if( LLayer_New(File, after, new_name) == LStatusOK ) 
return LLayer_GetNext (after) ; 

else 

return GetLLayer (File , new_name) ; 

} 

void copyLayerToTop (LFile File, LCell cell, LLayer 1) 

{ 

LLayer tmp; 
VISIBLE (1) ; 

assert ( tmp = createLayer (File, 1, " tmp_f or_copy" ) , "create tmp 



layer") ; 



IsOK( copyLayer (File, cell, tmp, 1, 0), "copy layer"); 
LSelection_DeselectAll ( ) ; 

IsOK(LSelection_AddAllObjectsOnLayer (tmp) , "find tmp") ; 
IsOK(LSelection_ChangeLayer (tmp, 1), "change tmp to 1"); 
LLayer_Delete (File, tmp) ; 
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* create left and right halves zones either side of the cut_line, 

* optionally generate ilayer, the work_layer in a zone around the 
cut_line 

* The later exist after the cut_line, left_area, right_ area [, ilayer] 
*/ 

LStatus create_half s ( LFile File, LCell cell, LLayer cut_line, LLayer 
work_layer ) 

{ 

LLayer wframe, both_sides; 

LLayer cut_copy, left_area, right_area, ilayer; 

LSelection sel; 

LObject obj ; 

LRect ebb; 

LRect bb; 

LRect rect; 

LRect frame; 

cut_copy = createLayer (File , cut_line, "cut^opy") ; 

/* create a copy of the cut line in the current level 

* cut_copy = cut 

* only way to detetrmine that a cut line exist in side the cell 

* at some level 
*/ 

IsOK( copyLayer (File, cell, cut_copy, cut_line, 0), "copy cut 

line"); 

LSelection_DeselectAll () ; 

if ( LSelection_AddAHObjectsOnLayer (cut_copy) != LStatusOK ) 

{ 

// LDialog_MsgBox ( "Error : No cut line found."); 
deleteTmpLayer (File, cut_copy) ; 
return LBadCell; 

} 

right_area = createLayer (File , cut_copy, "right_area" ) ; 
left_area = createLayer (File , cut_copy, "lef t_area" ) ; 
both_sides = createLayer (File , cut_copy, "both__sides " ) ; 
wframe = createLayer (File , cut_copy, "wframe"); 

ebb = LCell_GetMbb(cell) ; 

bb = selectionBbox ( ) ; 

frame. xO = cbb.xO; 
frame. xl = cbb.xl; 
frame. yO = bb.yO; 
f rame . y 1 = bb . y 1 ; 

// wframe = create a bounding box around the cut line to the edge 

of the cell 

LBox_New(cell, wframe, frame. xO, frame. yO, frame. xl, frame. yl) ; 

// cut wframe in half about the cut line 
// both_sides = ! cut & wframe; 

IsOK( generateLayer2op (File, cell, both_sides, NOT, cut_copy, 0, 
AND, ACTUAL, wframe, 0) , "cut out cut_line"); 

LSelection_DeselectAll () ; 

LSelection_AddAllObjectsOnLayer (both_sides) ; 
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LSelection_Merge ( ) ; 

sel = LSelection_GetList ( ) ; 
obj = LSelection_GetObject (sel) ; 
rect = LObject_GetMbb (obj ) ; 
if ( frame. xO != rect.xO ) 

{ 

sel = LSelection_GetNext (sel) ; 
obj = LSelection_GetObject (sel) ; 

} 

LSelection_RemoveObject (obj ) ; 

LSelection_ChangeLayer (both_sides, left_area) ; 

LSelection_AddAllObj ectsOnLayer (both_sides) ; 
LSelection_ChangeLayer (both_sides # right__area) ; 

if ( work_layer != NULL ) 

{ 

ilayer = createLayer (File, right_area, "ilayer"); 

// create a smaller bounding box hopefully to keep the work 

load down 

LSelection_DeselectAll () ; 

LSelection__AddAllObj ectsOnLayer (wf rame) ; 

LSelection_Clear () ; 

rect.xO = bb.xO - stitch_mar; 

rect.xl = bb.xl + stitch_mar; 

rect.yO = bb.yO; 

rect.yl = bb.yl; 

LBox_New (cell , wframe, rect.xO, rect.yO, rect.xl, rect.yl); 
// ilayer = layer of interest inside this bonding box 
// ilayer = wframe & layer 

IsOK( generateLayer2op (File, cell, ilayer, ACTUAL, wframe, 0, 
AND, ACTUAL, work_layer, 0), "layer of interest"); 
} 

deleteTmpLayer (File , both_sides) ; 
deleteTmpLayer (File , wframe) ; 
deleteTmpLayer (File, cut_copy) ; 
return LStatusOK; 

} 

void createSideMaterial (LFile File, LCell cell, 

LLayer t5, LLayer t6, LLayer t7, LLayer t8, 
LLayer side, LLayer not_side, LLayer side_area, 

LLayer maskSide, 

long spacing) 

{ 

LSelection_DeselectAll () ; 
LSelection_AddAllObj ectsOnLayer (t6) ; 
LSelection_AddAHObj ectsOnLayer (t7) ; 
LSelection_Clear ( ) ; 



// grow a little to recover & remote unwanted right side material 
// t6 = grow(t5,.15) & ! not_right 

// IsOK( generateLayer2op (File, cell, t6, ACTUAL, t5, 
stitch_mar/2 , AND, NOT, not_side, 0), "regrow and remove unwanted right"); 
if ( not_side ! = NULL ) 

{ 
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IsOK( generateLayer2op (File, cell, t6, ACTUAL, t5, 0, AND, 
NOT, not_side, 0) , "remove unwanted right") ; 

// t7 = grow (t6 ,. 275) or right_area 

IsOK( generateLayer2op (File, cell, t7, ACTUAL, t6, spacing, 
OR, ACTUAL, side_area, spacing), "merge right"); 

} 

else 

{ 

// t7 = grow(t5, .275) or right_area 

IsOK( generateLayer2op (File, cell, t7, ACTUAL, t5, spacing, 
OR, ACTUAL, side_area, spacing), "merge right"); 

} 

// t8 = grow ( t7, - .275) and ! right_area 

IsOK( generateLayer2op (File, cell, t8, ACTUAL, t7, -spacing, AND, 
NOT, side_area, 0), "remove right area") ; 

LSelection_DeselectAll () ; 
LSelection_AddAllObjectsOnLayer (t8) ; 
//LSelection_Merge ( ) ; 
LSelection_ChangeLayer (t8 , side) ; 
LSelection__DeselectAll () ; 
if ( not_side == NULL ) 

{ 

LSelection_AddAllObjectsOnLayer (side_area) ; 
LSelection_ChangeLayer (side_area, maskSide) ; 

} 

else 

{ 

LSelection_AddA110bjectsOnLayer (t6) ; 
LSelection_Clear () ; 

IsOK( generateLayer2op (File, cell, t6, ACTUAL, side_area, 0, 
AND, NOT, not_side, 0) , 

"remove not_side area"); 
LSelection_AddAllObj ectsOnLayer (t6) ; 
LSelection_ChangeLayer ( t6 , maskSide) ; 

} 

} 

void createSplitLayer (LFile File, LCell cell, LLayer work_layer) 

{ 

char layer_name [64] ,* 
char cut_name [64] ; 
char lef t_name [64] ; 
char right_name [64] 
char maskL_name [64] 
char maskR_name [64] 
char no_lef t_name [64] ; 
char no_right_ name [64] ; 
LLayer maskR; 
LLayer maskL; 

LLayer cut_line, left, right; 
LLayer not_left, not_right; 
LLayer ilayer, t4 , t5, t6; 
LLayer left_area, right_area, t7, t8; 
LSelection sel; 
LObject obj ; 
long spacing; 
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step_no = 0 ; 

if ( stitch_mar == 0 ) stitch_mar = LFile_LocUtoIntU (File , 

STITCH_MAR) ; 

if ( grid_step == 0 ) grid_step = LFile_LocUtoIntU (File, 

GRID_STEP) ; 

LLayer_GetName (work_layer , layer_name, 64); 

spacing = getSelf SpacingRule (File, layer_name)/ 2; 

strcpy (cut_name , layer__name) ; 
stmcat(cut_name, " cut line", 64); 
strcpy (lef t_name, layer_name) ; 
strncat (lef t_name, " left", 64); 
strcpy ( right_name , layer_name) ; 
strncat (right_name, " right", 64); 
strcpy (no_left_name , layer_ name) ; 
strncat (no_left_name , " not left", 64); 
strcpy (no_right_name , layer_name) ; 
strncat (no_right_name, " not right", 64); 
strcpy (maskL_name, layer_name) ; 
strncat (mas kL_name, " maskL", 64); 
s t r cpy ( ma s kR_name , 1 ay e r_name ) ; 
strncat (maskR_name, " maskR", 64); 

if ( (cut_line = GetLLayer (File, cut_name) ) == NULL ) return; 

if ( (left = GetLLayer (File, lef t_name) ) == NULL ) return; 

if ( (right = GetLLayer (File , right_name) ) == NULL ) return; 

if ( (maskL = GetLLayer (File , maskL__name) ) == NULL ) return; 

if ( (maskR = GetLLayer (File , maskR^name) ) == NULL ) return; 

// LFile_Save (File) ; 

VISIBLE (work_l aye r) ; 

VISIBLE (cut_line) ; 

VISIBLE (left) ; 

VISIBLE (right) ; 

VISIBLE (maskL) ; 

VISIBLE (maskR) ; 

if ( (not_left = LLayer_Find (File, no_left_name) ) != NULL ) 
VISIBLE (not_JLef t) ; 

if ( (not_right = LLayer_Find (File , no_right_name) ) != NULL ) 
VISIBLE (not_right) ; 

SetMsg ( layer_name , " " ) ; 
LSelection_DeselectAll () ; 

if ( LSelection_AddA110bjects0nLayer (lef t) == LStatusOK ) 
LSelection_Clear ( ) ; 

if ( LSelection__AddAllObjectsOnLayer (right) == LStatusOK ) 
LSelection_Clear ( ) ; 

if ( LSelection_AddAHObjectsOnLayer (maskL) == LStatusOK ) 
LSelection_Clear ( ) ; 

if ( LSelection_AddAHObjectsOnLayer (maskR) == LStatusOK ) 
LSelection_Clear ( ) ; 

if ( create_half s (File, cell, cut_line, work_layer) != LStatusOK 

) return; 

left_area = LLayer_GetNext (cut_line) ; 
right_area = LLayer_GetNext ( lef t_area) ; 
ilayer = LLayer_GetNext (right_area) ; 
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t8 


= createLayer ( 


File, 


i layer , 


., t8 « 


) ; 


t7 


« createLayer ( 


File, 


i layer, 


ii t7 « 


) ; 


t6 


= createLayer ( 


File, 


i layer, 


"t6" 


) ; 


t5 


= createLayer ( 


File, 


i layer, 


ll t5 H 


) ; 


t4 


= createLayer ( 


File, 


ilayer , 


M t4 „ 


) ; 



// create interestion area with cut line 
// t4 = ilayer AND cut 

IsOK( generateLayer2op (File, cell, t4, ACTUAL, ilayer, 0, AND, 
ACTUAL, cut_line, 0), "merge cut and ilayer"); 

// t5 = grow (t4, stitch_mar) ; 

IsOK( copyLayer (File, cell, t5, t4, stitch_mar) , "grow"); 



createSideMaterial (File, cell, t5, t6, t7, t8, left, not_left, 
left_area, maskL, spacing) ; 

createSideMaterial (File, cell, t5, t6, t7, t8, right, not_right, 
right_area, maskR, spacing) ,- 

deleteTmpLayer (File, t8) ; 
deleteTmpLayer (File, t7) ; 
deleteTmpLayer (File, t6) ; 
deleteTmpLayer (File, t5) ; 
deleteTmpLayer (File, t4) ; 
deleteTmpLayer (File, ilayer) ; 
deleteTmpLayer (File, left_area) ; 
deleteTmpLayer (File , right_area) ; 

} 

void createSplit (void) 
{ 

LFile File; 
LLayer 11; 

LCell cell; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 
11 = GetSelectedLayer (cell) ; 

if ( 11 != NULL ) createSplitLayer (File, cell, 11); 
resetUpi ( ) ; 

} 

void divide_material ( LCell cell, LObject cut_object, LLayer layer, 
LLayer left, LLayer right) 

{ 

LObject o; 
LRect bb; 
LPoint p; 

LSelection_DeselectAll ( ) ; 

for ( o = LObject_GetList (cell, layer); o != NULL; o = 
LObjectJSetNext (o) ) 

{ 

bb = LObject_GetMbb(o) ; 
p.x = (bb.xO + bb.xl)/2; 
p.y = (bb.yO + bb.yl)/2; 

if ( whichSideOfWire (cut_object, p) == LEFT ) 
{ 

LSelection_AddObject (o) ; 

} 

} 
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LSelection_ChangeLayer (layer , left) ; 
LSelection_DeselectAll () ; 
LSelection_AddAHObjectsOnLayer (layer) ; 
LSelection_ChangeLayer (layer , right) ; 
LSelection_DeselectAll ( ) ; 



void createDivideLayer (LFile File, LCell cell, LLayer work_layer) 

{ 

char layer_name [64] ; 

char cut_name [64] ; 

char lef t_name [64] ; 

char right_name [64] ; 

char psuedo_name [64] ; 

LLayer left__area, right_area; 

LLayer cut_line, left, right ; 

LLayer psuedo_layer ; 

LOb j ect cut_ob j ect ; 



if ( work_layer == NULL ) return; 
LLayer_GetName (work_layer , layer_name , 64 ) ; 

s t rcpy ( cut_name , layer_name ) ; 
st meat (cut_name, 11 cut line", 64); 
s t rcpy ( lef t_name , layer_name) ; 
strncat (lef t_name, " left", 64); 
strcpy (right_name , layer_name) ; 
strncat (right_name , " right", 64); 
strcpy (psuedo_name , "psuedo_" ) ; 
strncat (psuedo_name, layer_name, 64) ; 



if ( (cut_line = GetLLayer (File , cut_name) ) == NULL ) return; 

if ( (left = GetLLayer (File, left_name) ) == NULL ) return; 
if ( (right = GetLLayer (File, right_name) ) == NULL ) return; 
VISIBLE (work_layer ) ; 
VISIBLE (cut_line) ; 
VISIBLE (left) ; 
VISIBLE (right) ; 

if ( (psuedo_layer = LLayer_Find (File , psuedo_name) ) != NULL ) 
VISIBLE (psuedo_layer) ; 

step_no = 0; 

LSelection_DeselectAll ( ) ; 
LSelection_AddAllObjects0nLayer (left) ; 
LSelection_AddAHObjectsOnLayer (right) ; 
LSelection_Clear ( ) ,- 

LSelection_DeselectAll ( ) ; 

LSelection_AddAl!ObjectsOnLayer (cut_line) ; 
LSelection_Merge ( ) ; 

cut_object = LObject_GetList (cell, cut_line) ; 

assert ( LOb ject_Get Next (cut_object ) == NULL, "more than one cut 

area" ) ; 

divide_material (cell, cut_object, work_layer, left, right); 
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if ( psuedo_layer != NULL ) 

{ 

strcpy (lef t^name, psuedo_name) ; 
stmcat(left_name, " left", 64); 
strcpy ( right__name , psuedo_name ) ; 
strncat (right_name, " right", 64); 
left = GetLLayer (File, left_name) ; 
right = GetLLayer (File, right_name) ; 
VISIBLE (left) ; 
VISIBLE (right) ; 

divide_material (cell, cut_object, psuedo_layer , left, right); 

} 

} 

void createDivide (void) 

{ 

LFile File; 
LLayer 11; 

LCell cell; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 
11 = GetSelectedLayer (cell) ; 

if ( 11 != NULL ) createDivideLayer (File, cell, 11); 
resetUpi ( ) ; 

} 

/* 

* creates 3 new temperary layers left, right, work, 

* returns pointer to the left, and the other will follow it 

* left is the area to the left of the cut line, including the cut line 

* right is the area to the right of the cut line, including the cut line 

* work is a tempary layer for other to use 
*/ 

LLayer createOverlapFields (LFile File, LCell cell, char *layer_name) 

{ 

char cut_name [64] ; 

LLayer cut_line; 

LLayer left_area, right_area; 

LLayer t7; 

LLayer left, right, work; 



strcpy (cut _name, layer_name) ,- 
strncat (cut_name, 11 cut line", 64); 

if ( (cut_line = GetLLayer (File, cut_name) ) == NULL ) return 

NULL; 

VISIBLE (cut_line) ; 



if ( create_half s (File, cell, cut_line, NULL) != LStatusOK ) 

return; 

left_area = LLayer_GetNext (cut_line) ; 
right_area = LLayer_GetNext ( lef t_area) ; 
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t7 = createLayer ( File, right_area, "t7"); 
work = createLayer ( File, right_area, "work") ; 
right = createLayer ( File, right_area, "right"); 
left = createLayer ( File, right_area, "left"); 



generateLayer2op (File, cell, t7, ACTUAL, cut_line, 0, OR, ACTUAL, 
right_area, 0) ; 

LSelection_DeselectAll ( ) ; 
LSelection_AddAHObjectsOnLayer (t7) ; 
LSelection_ChangeLayer (t7 , lef t) ; 

LSelection_DeselectAll () ; 
LSelection_AddA110bjectsOnLayer (t7) ; 
LSelection__Clear ( ) ; 

generateLayer2op (File, cell, t7, ACTUAL, cut_line, 0, OR, ACTUAL, 
left_area, 0) ; 

LSelection_DeselectAll ( ) ; 
LSelection_AddAllObjectsOnLayer (t7) ; 
LSelection_ChangeLayer ( t7 , right) ; 

deleteTmpLayer (File , t7) ; 

if ( do_PWell ) 

{ 

LLayer pw_maskL, pw_maskR; 

pw_maskL = GetLLayer (File , "P Well maskL"); 
pw_maskR = GetLLayer (File , "P Well maskR"); 
LSelection_DeselectAll () ,- 

LSelection_AddAllObjectsOnLayer (right_area) ; 
LSelection_ChangeLayer (right_area, pw_maskR) ; 
LSelection_DeselectAll () ; 

LSelection_AddAHObjectsOnLayer (lef t_area) ; 
LSelection_ChangeLayer (lef t_area, pw_maskL) ; 

} 

deleteTmpLayer (File, right_area) ; 
deleteTmpLayer (File , lef t_area) ; 

return ( left ) ,- 

} 

void createOverlapLayer (LFile File, LCell cell, char *layer_name, LLayer 
left) 

{ 

char cut_name[64] ; 

char lef t_name [64] ,- 

char right_name [64] ; 

LLayer work_layer; 

LLayer work_left, work_right ; 

LLayer work, right; 

LSelection sel; 

LObject ob j ,- 

LRect bb; 

LRect rect ; 

LRect frame; 

LCoord tmp; 

LDerivedLayerParam *d; 

strcpy (lef t_name, 1 aye rename) ; 
s t meat (lef t_name, " left", 64); 
strcpy (right_name, layer_name) ; 
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strncat (right_name , " right", 64); 

if ( (work_layer = GetLLayer (File, 1 aye rename ) ) == NULL ) return; 

if ( (work_left = GetLLayer (File, lef t_name) ) == NULL ) return; 
if ( (work_right = GetLLayer (File , right_name) ) == NULL ) return; 
VISIBLE (work_layer) ; 
VISIBLE (work_left) ; 
VISIBLE (work_right) ; 

LSelection_DeselectAll () ; 

LSelection_AddAllObjectsOnLayer (work_lef t) ; 
LSelection_AddAHObjectsOnLayer ( worker ight) ; 
LSelection_Clear ( ) ; 

right = LLaye r_Get Next ( lef t ) ; 
work = LLaye r_GetNext (right ) ; 



// work = work_layer & left 

generateLayer2op (File, cell, work, ACTUAL, work_layer, 0, AND, 
ACTUAL, left, 0) ; 

LSelection_DeselectAll () ; 
LSelection_AddAHObjectsOnLayer (work) ; 
LSelection_ChangeLayer (work, work_l eft ) ; 

// work = work_layer & right 

generateLayer2op (File, cell, work, ACTUAL, work_layer, 0, AND, 
ACTUAL, right, 0) ; 

LSelection_DeselectAll () ; 
LSelection_AddAHObjectsOnLayer (work) ; 
LSelection_ChangeLayer (work, work_r ight ) ; 



void doOverlappingSplit (LFile File, LCell cell) 

{ 

LLayer left, right, work; 

left = createOverlapFields (File, cell, "P Well"); 

if ( left == NULL ) 

{ 

return; 

} 

right = LLaye r_Get Next (lef t) ; 
work = LLayer_GetNext (right ) ; 

if ( do_NDif fusion ) createOverlapLayer (File , cell, "N 
Diffusion" , left) ; 

if ( do_PDif fusion ) createOverlapLayer (File, cell, "P 
Diffusion" , left) ,- 

if ( do__NTie ) createOverlapLayer (File, cell, "NTie", left) ; 

if ( do_PTie ) createOverlapLayer (File, cell, "PTie", left) ; 

if ( do_NWell ) createOverlapLayer (File, cell, "N Well", 

left) ,- 

if ( do_PWell ) createOverlapLayer (File, cell, "P Well", 

left) ; 

if ( do_PSelect ) createOverlapLayer (File , cell, "P+ Select", 

left) ; 
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left) ; 



} 



if ( do NSelect ) createOverlapLayer (File, cell, "N+ Select", 



deleteTmpLayer (File, work) ; 
deleteTmpLayer (File, right) ; 
deleteTmpLayer (File, left) ; 



LCell completeSplit (LFile File, LCell cell) 
{ 

char cell_name [64] ; 
char new_name [64] ; 
LCell New; 
LLayer 1 ; 



assert ( LCell GetName (cell , cell name, 64) != NULL, "no cell 



name " ) ; 



strcpy (new_name, cell_name) ; 
strncat (new_name, "_cut", 64 ); 
SetMsg (cell_name, new_name) ; 
LCell_Copy (File, cell, File, new_name) ; 

assert( (New = LCell_Find (File , new_name) ) != NULL, "new cell 
creation failed"); 

New = LCell_Flatten(New) ; 
assert(New != NULL, "flatten side"); 
LCell_MakeVisibleNoRef resh (New) ; 

createSplitLayer (File , New, GetLLayer (File, 

createSplitLayer (File, New, GetLLayer (File , 

createSplitLayer (File, New, GetLLayer (File , 

createSplitLayer (File, New, GetLLayer (File, 

createSplitLayer (File , New, GetLLayer (File , 







if 


( do_ 


^Poly ) 




"Poly") ) 


/ 














if 


( do_ 


JVIetall 


) 


"Metall" 


) ) ; 














if 


( do_ 


_^Metal2 


) 


"Metal2" 


) ) ; 














if 


( do_ 


_Metal3 


) 


"Metal3" 


) ) ; 














if 


( do_ 


_Metal4 


) 


"Metal4" 


) ) ; 














if 


( do_ 


_Contact 


) 


"Contact 


") ) 


if 


( do_ 


_Vial ) 




"Vial") ) 


i 


if 


( do_ 


_Via2 ) 




"Via2") ) 


i 


if 


( do_ 


_Via3 ) 




"Via3" ) ) 


i 


if 


( do_ 


_Glass ) 




"Glass") ) ; 











createDivideLayer (File, New, GetLLayer (File , 

createDivideLayer (File, New, GetLLayer (File, 

createDivideLayer (File, New, GetLLayer (File, 

createDivideLayer (File , New, GetLLayer (File , 

doOverlappingSplit (File, New) ; 

LSelection_DeselectAll () ; 

1 = GetLLayer (File, "n+ implant"); 

VISIBLE (1) ; 

LSelection_AddAllObjectsOnLayer (1) ; 
LSelection_Clear ( ) ; 
1= GetLLayer (File, "p+ implant"); 
VISIBLE (1) ; 

LSelection_AddAHObjectsOnLayer (1) ; 
LSelection_Clear ( ) ; 
1= GetLLayer (File, "nwell"); 
VISIBLE (1) ; 

LSelection_AddAllObjectsOnLayer (1) ; 



1050 



LSelection_Clear () ; 
return New; 

} 



void makes ideLayer2 (LFile File, LCell Cell, char *l_name, halves Side, 
int copy, char *omask_ext) 

{ 

char s_name[64],- 
char o_name[64] ; 
char m_name[64] ; 
char c_name [64] ; 
LLayer Layer_mask; 
LLay e r Lay e r_s i de ; 
LLayer Layer_orig; 
LLayer Layer_other; 
LLayer Layer_cut; 
char cell_name [64] ; 

char *oside_ext = (Side == RIGHT)? " left" : " rights- 
char *side_ext = (Side == LEFT)? » left" : " rights- 
assert ( LCel l_Get Name (Cell , cell__name, 64) != NULL, "no cell 

"); 

Set Msg (cell_name , l_name) ; 

// LDialog_MsgBox (cell_name) ,- 

strcpy (s_name,. l_name) ; 
strncat (s_name, side_ext, 64); 
s t r cpy ( o_name , l_name ) ,- 
strncat (o_name , oside_ext, 64); 

Layer_orig = GetLLayer (File , l_name) ,- 
assert (Layer_orig != NULL , l_name ) ; 
VISIBLE (Layer_orig) ,- 

Layer_side = GetLLayer (File , s_name) ; 
assert (Layer_side ! = NULL, s_name) ; 
VISIBLE (Layer_side) ; 

Layer_other = GetLLayer (File, o_name) ; 
assert (Layer_other != NULL , o_name ) ; 
VISIBLE (Layer_other) ; 

LSelect ion_DeselectAll ( ) ; 

if ( omask_ext != NULL ) 
{ 

LRect r, c; 
LPoint p; 
LObject o; 
LLayer tmp; 

s t r cpy ( m_name , l_name ) ; 
strncat (m_name, omask_ext , 64); 
Layer_mask = GetLLayer (File , m_name) ; 
assert (Layer_mask != NULL , m_name ) ; 
VISIBLE (Layer_mask) ,- 
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strcpy (c_name , l_name) ; 
strncat (c_name, " cut line", 64); 
Layer_cut = GetLLayer (File, c_name) ; 
assert (Layer_cut 1 = NULL , c_name ) ; 
VISIBLE (Layer_cut) ; 

IsOK(LSelection_AddAllObjectsOnLayer (Layer_cut) , "get 

cut_line" ) ; 

r = selectionBboxO ; 

c = LCell_GetMbbAll (Cell) ; 

if ( Side == LEFT ) 

p.x = c.xO = r.xl; 

else 

p.x = c . xl = r.xO; 
p.y = 0; 

LSelection_DeselectAll () ; 

LSelection_AddAllObj ectsOnLayer (Layer_orig) ; 
LSelection_SliceVertical (&p) ; 

// tmp = createLayer (File, Layer_cut , " tmp_mask" ) ; 



// generateLayer2op ( File, Cell, tmp, ACTUAL, Layer_orig, 0, 
AND, ACTUAL, Layer_mask, 0) ; 

// LSelection_AddAllObjectsOnLayer (tmp) ; 
// LSelection_ChangeLayer (tmp, Layer_side) ; 

// LSelection_DeselectAll () ,* 

// for ( o = LObject_GetList (Cell , Layer_orig) ; o != NULL; o 
= LObject_GetNext (o) ) 
// { 

// switch ( LObject_GetShape (o) ) 

// { 

// case LTorus : 
// case LCircle: 
// case LPie: 

// LSelection_AddObject (o) ; 

// break; 

// } 

// > 

LSelection_RemoveA110bjectsInRect (&c) ; 
LSelection_Change Layer (Layer_orig, Layer_side) ; 
LSelection_DeselectAll () ; 

LSelection_AddAllObj ectsOnLayer (Layer_orig) ; 
LSelection_AddAllObjectsOnLayer (Layer_mask) ; 
LSelection_Clear () ; 
// LLayer_Delete (File, tmp) ; 

} 

// delete the other side material 
LSelection_AddAHObj ectsOnLayer (Layer_other) ; 
LSelection_Clear () ; 

if ( copy == 0 ) 

{ 

// delete orig material and copy the 
// side material to it 



LSelecti on_AddAl 1 Ob j e c t s OnLay e r ( Lay e r_or i g ) ; 
LSelection__Clear ( ) ; 

LSelection__AddAHObj ectsOnLayer (Layer_side) ; 
LSelection_ ChangeLayer (Layer_side, Layer_orig) ; 



1052 



} 

// else keep both 

} 

void makeSideCell2 (LFile File, LCell Cell, halves Side) 
{ 

char *omask_ext = (Side == RIGHT)? " maskL" : " maskR" ; 
LLayer 1; 



LCell_MakeVisibleNoRefresh(Cell) ; 





if 


( do Poly ) make Side Layer 2 ( File , Cell, "Poly", 


Side , 


^ 0 \^ i lid Jw 


ext) ■ 




if~ 


( do Metall ) makes ide Lave r 2 (File . Cell. "Metall". Side. 


omask 


ext) ; 






if 


( do Metal2 ) makeSideLayer2 (File , Cell, "Metal2", Side, 


oma.sk 


ext) ; 






if 


( do Metal3 ) makeSideLayer2 ( File , Cell, "Metal3" , Side, 


omask 


ext ) ; 






if 


( do Metal4 ) makeSideLayer2 (File, Cell, "Metal4", Side, 


omask 


ext ) ; 






if 


( do Contact ) makeSideLayer2 (File, Cell, "Contact", 


Side , 


0 NULL) • 






if 


( do Vial ) makeS ideLaver2 (File Cell "Vial" 


Side , 


0 NULL) ■ 






if 


( do Via2 ) makeSideLaver2 (File . Cell. "Via2". 


Side , 


0 NULL) • 






if 


( do Via3 ) makeSideLayer2 (File, Cell, "Via3", 


Side , 


0 NULL) • 

W , A> V«* J_l J_i / , 






if 


( do Glass ) makeSideLayer2 (File , Cell, "Glass", 


Side , 


0 NULL) • 






if 


( do Contact ) makeSideLayer2 (File, Cell, "psuedo Contact 




Side 0 


NULL) • 




if 


( do Vial ) makeSideLaver2 (File Cell "nsuedo Vial" 




O J- LAC , \J , 


NTTLL) • 




if 


( do Via? ) malcefi i rfpTiavpr? / pi 1 p fpl 1 •'nQiipfin Vi a 9 " 

V v-i^ v -i. C4 / iuaj\c i-J -i- ucua y j_ ^ \ i xic y • ~ J- J- , o ucuu v jl d , 




O J- UC. , \J t 


MTTT.T.) • 

lMUiJiJ / , 




if 


f do Via*} ) malrpS i rfpTiavPT*? f pi 1 p CeT T "nQnpHn vi " 




Side* 0 


NULL) • 




if 


( do_Glass ) makeSideLayer2 (File, Cell, "psuedo_Glass " , 




Side, 0, 


NULL) ; 




if 


( do_NDif fusion ) makeSideLayer2 (File , Cell , "N Diffusion" 




Side, 0, 


NULL) ; 




if 


( do_PDif fusion ) makeSideLayer2 (File , Cell , "P Diffusion" 




Side, 0, 


NULL) ; 




if 


( do_NTie ) makeSideLayer2 (File , Cell, "NTie", 


Side, 


0, NULL) ; 






if 


( do_PTie ) makeSideLayer2 (File, Cell, "PTie", 


Side, 


0, NULL) ; 






if 


( do_NWell ) makeSideLayer2 (File, Cell, "N Well", Side, 


NULL) ; 








if 


( do_PWell ) makeSideLayer2 (File, Cell, "P Well", Side, 


omask_ 


ext) ; 






if 


( do_PSelect ) makeSideLayer2 (File, Cell, "P+ Select", 


Side, 


0, NULL) ; 






if 


( do_NSelect ) makeSideLayer2 (File , Cell, "N+ Select", 


Side, 


0, NULL) ; 





} 
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void makeNewSideCell (LFile File, LCell Cell, halves Side) 

{ 

char cell_name [64] ; 
char new__name [64] ; 
LCell New; 

assert ( LCel l_Get Name (Cell , cell_name, 64) 

name " ) ; 

strcpy (new_name, cell_name) ; 
strncat (new_name, (Side == LEFT) ? "_left" 
SetMsg (cell_name, new__name) ; 
LCel l_Copy (File, Cell, File, new_name) ; 
assert ( (New = LCell_Find (File , new_name) ) 
creation failed"); 

makes ideCel 12 (File, New, Side) ; 

} 

void doOverlapSplit (void) 
{ 

LFile File; 
LCell cell; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 
doOverlappingSplit (File, cell) ; 
resetUpi ( ) ; 

} 



!= NULL, "no cell 
: "_right", 64); 
!= NULL, "new cell 



void see_cut_layers ( ) 

{ 

LFile File; 
LCell Cell_Draw; 

if ( (Cell_Draw = getCurrentCell (&File) ) == NULL ) return; 
// cut on 

make_visible ( GetLLayer (File , "cut start"), 
GetLLayer (File, "cut end"), 
LVisible, LIGNORE, File) ; 

resetUpi ( ) ,- 

} 

void splitAllInstances ( ) 
{ 

LFile File; 
LLayer 1; 
LCell cell; 
LCell subcell; 
LInstance inst; 
int delete = 0 ; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return,- 

for ( inst = LInstance_GetList (cell ) ; inst != NULL; inst = 
LInstance_GetNext (inst) ) 
{ 

subcell = LInstance_GetCell (inst) ; 
createSidesDo (File, subcell) ; 
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} 

LCell_MakeVisibleNoRefresh(cell) ; 
resetUpi ( ) ,- 

} 

char *cutname( char *orig, char *new, halves Side, int n) 

{ 

char *ptr; 

strncpy (new, orig, n) ; 

strncat (new, (Side == DONOTKNOW) ? "_join" : (Side == LEFT) ? 
"_cut_left" : "_cut_right" , n) ; 

return ( new ) ; 

} 

/* copy cell to cell_cut_SIDE or cell_join, and replace all instances 

with 

* subinst_cut_side if they exist 
*/ 

void createEnd (LFile File, LCell Cell, halves Side) 

{ 

char cell_name [128] ,- 
char new__name [12 83 / 
LCell New; 
LCell subcell ,- 
LCell newsub; 
LInstance inst; 
LInstance ninst; 
LTransform xform; 
LPoint repeat, delta; 

assert ( LCell_GetName (Cell , cell_name, 128) != NULL, "no cell 

name " ) ; 

cu t name (eel l_name , new_name, Side, 128); 
LCell_Copy (File, Cell, File, new_name) ; 

assert ( (New = LCell_Find (File , new_name) ) != NULL, "new cell 
creation failed"); 

for ( inst = LInstance_GetList (New) ,- inst != NULL; inst = ninst ) 

{ 

ninst = LInstance_GetNext (inst) ; 
subcell = LInstance_GetCell (inst) ; 

assert ( LCell_GetName ( subcell , cell_name, 128) != NULL, "no 
(sub) cell name"); 

xform = LInstance_GetTransf orm (inst) ; 
if ( xform. orientation == 0 ) 

cutname (cell_name, new_name, Side, 128); 

else 

cu t name (eel l_name, new_name, otherSide (Side) , 128) ; 
if ( (newsub = LCell_Find (File , new_name) ) != NULL ) 

{ 

if ( (newsub = LCell_Find (File , new_name) ) == NULL ) 

{ 

LDialog_MsgBox ( "Error : side subside does not 



exists . " ) ; 



LDialog_MsgBox (new_name) ; 
return; 

} 

repeat = LInstance_GetRepeatCount (inst ) ; 
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delta = LInstance_GetDelta (inst) ; 

if ( LInstance_New(New,newsub,xform, repeat, delta) == 

NULL ) 

{ 

LDialog_MsgBox ( "Error : side sub instance creation 

failed. ") ; 

LDialog_MsgBox (new_name) ; 

} 

LInstance_Delete (New, inst) ; 

} 

} 

} 

mergeLayers (LFile File, LCell cell, LLayer work_layer, LLayer side, 
LLayer mask, 

LLayer t8, LLayer t9) 

{ 

LObject o, n; 
LObject b; 
LRect r; 

generateLayer2op (File, cell, t8, ACTUAL, side, 0, AND, ACTUAL, 

mask, 0) ; 

LSelection_DeselectAll ( ) ; 
LSelection_AddAHObjectsOnLayer (t8) ; 
LSelection_ChangeLayer ( t8 , work_layer) ; 

if ( t9 1= NULL ) 
{ 

for ( o = LObject_GetList (cell, side); o != NULL; o = n ) 

{ 

n = LObject_GetNext (o) ; 
switch ( LObject_GetShape (o) ) 

{ 

case LTorus : 
case LCircle : 
case LPie : 

r = LObject_GetMbb (o) ; 

b = LBox_New(cell, t9, r.xO, r.yO, r.xl, r.yl) ; 
generateLayer2op (File, cell, t8, ACTUAL, t9, 0, AND, 

ACTUAL, mask, 0) ; 

LSelection_DeselectAll () ; 

if ( LSelection_AddAllObjectsOnLayer (t8) == LStatusOK 

) 

{ 

LSelection_Clear ( ) ; 

LObject_ChangeLayer (cell, o, work_layer ); 

} 

break; 

} 

} 

} 

} 

void mergeSides (LFile File, LCell cell, char *layer_name) 

• { 

LLayer work_layer; 
char cut_name [64] ; 
char lef t_name [64] ; 
char right_name [64] ; 
char maskL_name [64] ; 
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char maskR_name [64] ; 
char no_lef t_name [64] ; 
char no_right_name [64] ; 
LLayer maskR; 
LLayer maskL; 

LLayer cut_lirie, left, right; 
LLayer left_area, right_area, t8, t9; 
LSelection sel; 
LObject ob j ; 



if ( (work_layer = GetLLayer (File , layer_name) ) == NULL ) return; 

strcpy(cut_name, layer^name) ; 
strncat (cut_name, " cut line", 64); 
strcpy ( lef t_name , layer_name) ; 
strncat (left_name, " left", 64); 
strcpy ( right_name , layer_name ) ; 
strncat (right_name, " right", 64); 
strcpy (mas kL^name , layer_name) ; 
strncat (mas kL__name , " maskL", 64); 
strcpy (maskR_name, layer_name) ; 
strncat (mas kR_name, " maskR", 64); 



if ( (cut_line = GetLLayer (File , cut_name) ) == NULL ) return; 

if ( (left = GetLLayer (File, left_name) ) == NULL ) return; 

if ( (right = GetLLayer (File , right_name) ) == NULL ) return; 

if ( (maskL = GetLLayer (File , maskL_name) ) == NULL ) return; 

if ( (maskR = GetLLayer (File , maskR_name) ) == NULL ) return; 



VISIBLE (work_layer) ; 
VISIBLE (left) ; 
VISIBLE (right) ; 
VISIBLE (maskL) ; 
VISIBLE (maskR) ; 



t8 = createLayer ( File, cut_line, "t8"); 

t9 = createLayer ( File, cut_line, "t9"); 

mergeLayers (File, cell, work_layer, left, maskR, t8, t9) ; 

mergeLayers (File, cell, work_layer, right, maskL, t8, t9) ; 

mergeLayers (File, cell, work_layer, right, left, t8, NULL) ; 



LSelection_DeselectAll () ; 
LSelection_AddAHObjectsOnLayer (right) 
LSelection__AddAHObjectsOnLayer (left) ; 
LSelection_AddAHOb j ectsOnLayer (maskL) 
LSelection_AddAHObjectsOnLayer (maskR) 
LSelection Clear (); 



deleteTmpLayer (File, t8) ; 
deleteTmpLayer (File, t9) ; 

} 

copyPorts (LCell orig, LCell New) 

{ 

LPort port; 
char pname[50] ; 
LLayer 1; 
LRect r; 



for( port = LPort_GetList (orig) ; port != NULL; port = 
LPort_GetNext (port) ) 
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{ 

LPort_GetText (port, pname, 50) ; 
1 = LPor t_Get Layer (port) ; 
r = LPort_GetRect (port ) ; 

assert (LPort_New (New, 1, pname, r.xO, r.yO, r.xl, r.yl) , "copy 

port fail") ; 

} 

} 

void createJoin(LFile File, LCell cell) 

{ 

char cell_name [128] ; 
char new_name [12 8] ; 
char sub_name [128] ; 
LCell New; 
LCell subcell; 
LInstance inst ; 
LInstance ninst; 
LTransform xform; 
LPoint repeat, delta; 

assert ( LCel l_Get Name (cell , cell_name, 128) != NULL, "no cell 

name " ) ; 

strcpy (new_name, cell_name) ; 
strcat (new__name, "_join"); 

cutname (cell_name , sub_name, LEFT, 128); 

assert ( (subcell = LCell_Find (File , sub_name) ) != NULL, "find 

left side") ; 

LCell_Copy (File, subcell, File, new_name) ; 

assert( (New = LCell_Find (File, new_name) ) != NULL, "new join 
cell creation failed"); 

xform. translation . x = 0; 
xform. translation . y = 0; 
xform. orientation = 0; 
xform. magnificat ion. num = 1; 
xform. magnificat ion. denom = 1; 
repeat . x = 1 ; 
repeat . y = 1 ; 
delta.x = 1; 
delta. y = 1; 

cutname (eel l_name, new_name, RIGHT, 128); 

assert ( (subcell = LCell_Find (File , new_name) ) != NULL, "find 
right side" ) ; 

LInstance_New (New, subcell , xform, repeat, delta); 
LCell_MakeVisibleNoRef resh (New) ,- 
New = LCell_Flatten (New) ; 



if 


( 


do 


Poly 


) 


mergeSides (File, 


New, 


"Poly") ; 


if 


( 


do 


"Metal 1 


) 


mergeSides (File, 


New, 


"Metall") 


if 


( 


do 


~Metal2 


) 


mergeSides (File, 


New, 


"Metal2" ) 


if 


( 


do" 


~Metal3 


) 


mergeSides (File, 


New, 


"Metal3") 


if 


( 


do" 


"Metal4 


) 


mergeSides (File, 


New, 


"Metal4") 


if 


( 


do" 


"pwell 


) 


mergeSides (File, 


New, 


"P Well") 



copyPorts (cell, New) ; 



void createSidesDo (LFile File, LCell cell) 

{ 



1058 



LCell cut_cell; 

LCe 1 l_Make Vi s i b 1 eNoRe f r e s h ( c e 1 1 ) ; 
cut_cell = completeSplit (File, cell); 
makeNewSideCell (File, cut_cell, LEFT) ; 
makeNewSideCell (File, cut_cell, RIGHT) ; 
createJoin (File, cell) ; 

} 

void createSides (void) 
{ 

LFile File; 

LCell cell; 
LCell cut_cell; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 
createSidesDo (File, cell) ; 
resetUpi ( ) ; 

} 

void createEnds (LFile File, LCell Cell) 

{ 

createEnd (File, Cell, LEFT) ; 
createEnd(File, Cell, RIGHT); 
createEnd (File, Cell, DONOTKNOW) ; 

} 

void do_createEnds ( ) 

{ 

LFile File; 
LCell cell; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 
createEnds (File, cell) ; 
resetUpi ( ) ; 

} 

void copy_cut_lines ( ) 
{ 

LFile File; 
LCell cell; 

LLayer 11, start, end; 
char lname [64] ; 
char *ptr; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 

start = GetLLayer (File, "cut start"); 
end = GetLLayer (File, "cut end"); 

for ( 11 = LLayer_GetNext (start) ; 11 != end; 11 = 
LLayer_GetNext (11)) { 

LLay e r_Ge t Name (11, 1 name , 64); 

ptr = lname + strlen (lname) - 9; 

if ( strcmp( ptr," cut line") == 0 ) 
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{ 

copyLayerToTop (File, cell, 11) ; 

} 

} 

resetUpi ( ) ; 

} 

void see_cut_lines ( ) 

{ 

LFile File; 
LCell cell; 

LLayer 11, start, end; 
char lname [64]; 
char *ptr; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return,- 

start = GetLLayer (File, "cut start") ; 
end = GetLLayer (File, "cut end"); 

for ( 11 = LLayer_GetNext (start) ; 11 != end; 11 = 
LLayer_Ge tNext ( 1 1 ) ) { 

LLayer_GetName (11, lname , 64 ) ; 

ptr = lname + strlen (lname) - 9; 

if ( strcmp( ptr," cut line") == 0 ) 

{ 

VISIBLE (11) ; 

} 

} 

resetUpi () ; 

} 



void createEndsAHInstances ( ) 

{ 

LFile File; 
LLayer 1 ; 
LCell cell; 
LCell subcell; 
LInstance inst; 
int delete = 0; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 

for ( inst = LInstance_GetList (cell ) ; inst != NULL; inst = 
LInstance_Ge tNext (inst) ) 

{ 

subcell = LInstance_GetCell (inst) ; 
createEnds (File, subcell) ; 

} 

LCe 1 l_Make Vi s ib 1 eNoRe f r e sh ( c e 1 1 ) ,- 
resetUpi ( ) ; 

} 

void createJoinDo (void) 
{ 

LFile File; 
LCell cell; 
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LCell cut_cell; 

if ( (cell b getCurrentCell (&File) ) == NULL ) return; 
createJoin (File, cell); 
resetUpi ( ) ; 

} 

void createJoinAHInstances () 

{ 

LFile File; 
LLayer 1 ; 
LCell cell; 
LCell subcell; 
LInstance inst; 
int delete = 0; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 

for ( inst = LInstance_GetList (cell ) ; inst != NULL; inst = 
LInstance_GetNext (inst) ) 

{ 

subcell = LInstance_GetCell (inst) ; 
createJoin (File, subcell); 

} 

LCell_MakeVisibleNoRef resh (cell) ; 
resetUpi () ; 

} 

void doAll () 
{ 

LFile File; 
LCell cell; 
LInstance inst; 
LObject o; 
LLayer 1 ; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 

// cell = LCell_Find(File, "gen_gds_list " ) ; 
// LCell_MakeVisibleNoRef resh (cell) ; 
// genGDSforAHInstance ( ) ; 

cell = LCell_Find(File, " stitch_list " ) ; 
LCell_MakeVisibleNoRef resh (cell) ; 
splitAllInstances () ; 

cell = LCell_Find(File, "endl_list " ) ; 
LCell_MakeVisibleNoRef resh (cell) ; 
createEndsAllInstances () ; 

cell = LCell_Find(File, "end2_list " ) ; 
LCe 1 l_Make Vi s ib 1 eNoRe f r e sh ( c e 1 1 ) ; 
createEndsAllInstances ( ) ; 

resetUpi () ; 

} 

void delete_joins ( ) 
{ 

LFile File; 



1061 



LCell cell; 

LCell ncell; 

char *ptr; 

char cell_name [64] ; 

if ( (cell = getCurrentCell (&File) ) == NULL ) return; 

for( cell s LCell_GetList (File) ; cell != NULL; cell = ncell ) 
{ 

ncell = LCell_GetNext (cell) ; 

assert ( LCell_GetName (cell , cell_name, 64) != NULL, "no cell 

name " ) ; 

ptr = cell_name + strlen (cell_name) - 5; 
if ( strcmp( ptr, "_join") == 0 ) 

{ 

if ( LDialog_YesNoBox (cell_name) ) 
LCell_Delete (cell) ; 

} 

} 



} 



re setup i ( ) ; 



#if INTERP 

void stitch_macro_register ( void ) 
#else 

int UPI_Entry_Point ( void ) 

#endif 

{ 

LMacro_Register ( "create Split", "createSplit " ) ,- 

LMacro_Register (" create Divide", " createDivide" ) ; 

LMacro_Register ( "do overlap split", "doOverlapSplit " ) ; 

LMacro_Register ( "create Sides", "createSides" ) ; 

// LMacro_Register ( "create Join", " create JoinDo" ) ; 

LMacro_Register (" split all instances", "splitAllInstances" ) 

LMacro_Register ( "Set up Split", "SetupSplitLayers " ) ; 

LMacro_Register ( "See cut layers", "see_cut_layers") ; 

LMacro_Register ( "See cut lines", " see_cut_lines " ) ; 

LMacro_Register ( "Copy cut lines", "copy_cut_lines " ) ; 

LMacro_Register ( "create ends cells", "do_createEnds " ) ; 

LMacro_Register ( "create ends all instances", 
"createEndsAllInstances" ) ,- 

// LMacro_Register ( "create join all instances", 
"createJoinAllInstances" ) ; 

LMacro_Register ("do all", "doAll"); 

LMacro_Register ( "delete _join cells", "delete_joins" ) ; 

#if ! INTERP 

return 1 ; 

#endif 

} // End of Function: UPI_Entry_Point 
#if INTERP 

} /* End of Module hierarchy */ 
stitch_macro_register ( ) ; 
#endif 
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